Login Options

Pages

How the Web works, and why you should care (Part II).

In the last installment we discussed the Internet and its infrastructure.  Today we will delve into how web servers work with your browser.  There are many web technologies that exist, and more and more are added each month.  However, the basics of the World Wide Web have remained unchanged, and that is out topic for today.

Again, you might ask, “Why should I care?”  You might ponder on how much knowledge of internet technologies is good enough for a business leader to have.  Afterall, after a certain point can’t we just leave it to the IT guys?  Again, I would encourage you to learn as much as you can, given the constraints of your time.  Otherwise you won’t be able to effectively manage your IT projects and operations.

“IT guys” have specialities.  Depending on what your company is trying to accomplish you need to hire the right folks for the job.  Depending on the specialities of your existing staff you may want to invest in computers, network equipment, and projects that use specific technologies that your staff is familiar with.  Having an overall understanding of how the World Wide Web works is going to do nothing but help you make informed business decisions on how you invest your IT dollars.

Web Servers, Input and Output Programs

A website is fundamentally a Client-Server program that runs on a Web Server, and is accessed through Clients, which are all the web browsers and automated systems that request information from it using the HTTP or HTTPS protocol.  Web browsers run on computers, and these days even on cell phones.  They are not the computer itself, but rather are software applications (such as Internet Explorer or Mozilla) that runs on these devices.  Similarly, Web Servers (such as Internet Information Server (IIS) or Apache) are also a software application that run on usually more powerful computers.  The job of the client software is to accept user input (through the keyboard and mouse usually) and then contact the remote computer running the Web Server software.  The Web Server handles the requests of the clients, and spits back the information requested to the client’s browser.  The client’s browser, then displays the information it has received from the web server, and displays it to the user.

The web browser usually requests a page or resource on the website, such as http://www.millcreekwebworks.com/default.aspx which is the Mill Creek WebWorks home page.  The web server accepts this request, processes it, and determines what HTML content it should return to the client’s web browser for display.  When you click on a link or a button in your browser, you are usually telling the browser to request a new page or resource from the website.  In the old days, you would not have a page called default.aspx.  The .aspx file extension is specifically a file dedicated to websites built in Microsoft ASP.NET.  Before ASP.NET or any of the other complex server-side technologies were developed, there were only static HTML pages and CGI scripts written in Perl and other compiled lagnuages.  HTML pages have a file extension of .htm or .html, and are files that contain the complete set of characters in HTML that is returned to the client’s web browser.  They are literally a file that resides on the web server, and if you were to login into the web server computer you could open up the HTML file in a text editor like Notepad and see it for yourself.  The HTML file can’t accept parameters, so therefore you couldn’t change things based on what users might type into a text input or anything like that.  The web server will return the same output every single time.  The original HTML specifications did allow for user inputs, like text boxes and checkboxes, but you had to write a CGI script to process the user input.  The script written in Perl was like a mini program.  When the Web Server was instructed to go to a CGI script, it would pass on the parameters of an HTML form to the program.  The program could then process these input variables, perform a storage or database update, and then could either redirect the user to a different HTML page (based on what was inputted), or spit back custom HTML based on the user input.  Perl Scripts were really the predecessors to all the custom and dynamic websites we see today.  Without them the Web was simply a one way communication of static information from the web server to users.  Without them you couldn’t do a Google search, or make an eCommerce purchase, or anything. With them it was the beginning of being able to build truly interactive applications on the Web.

These days the information returned by the Web Server includes much more than straight HTML.  It includes CSS, Javascript, XML, graphics, and sound.  We will discuss all of these complexities and what they do in our next segment.

1 comment to How the Web works, and why you should care (Part II).

  1. News How the Web works, and why you should care (Part II). | Web 2.0 Designer
    July 17th, 2009 at 9:07 am

    […] Read more: How the Web works, and why you should care (Part II). […]

Leave a Reply

You must be logged in to post a comment.