How Web Applications Work
How Web Applications Work
A Client Computer requests a service. Server Computer checks whether the request is valid/Invalid and if
the request is valid , it searches and provides the service and then the Client Computer consumes/utilizes
that service.
*** Services: describe what a server on the network offers to parties that want to communicate
For Example, According to the Restaurant Network: The Client and the Server
explained, both client and server are human beings. But their activities differ.
*** Client has Requests and Server provides access to the Resources by validating the Requests.
Web Application: program that is stored on a remote server and delivered over the Internet through a
browser interface. It runs on principle of Client-Server Architecture. Examples include gmail, facebook
and instagram.
1. A web browser lets a user request a resource. The web server gets the request, finds the resource,
and returns something to the user.
2. Resource is an HTML page/picture/sound file/PDF document. Doesn’t matter—the client asks for
the thing (resource) and the server sends it back.
3. “404 Not Found” error—the response you get when the server can’t find what it thinks you asked
for.
4. When we say “server”, we mean either the physical machine (hardware) or the web server
application (software).
A web client lets the user request something on the server, and shows the user the result of the request.
1. Clients --- both (or either) the human user and the browser application doing what the user asked
it to do.
2. Browser --- software (like Chrome or Mozilla) that knows how to communicate with the server.
3. Browser --- interpreting(translate) the HTML code and rendering the web page for the user.
*** The client uses HTTP to request something from the server
1. Request Line --- The first line of the header is called the request line, followed by optional request
headers. The request line has the following syntax:
request-method-name request-URI HTTP-version
request-method-name: request methods like GET, POST.The client can use one of these methods to
send a request to the server.
request-URI: specifies the resource requested.
HTTP-version: Two versions are currently in use: HTTP/1.0 and HTTP/1.1 and HTTP/2.0
(published in 2015).
2. The request headers are in the form of name:value pairs. Multiple values, separated by commas,
can be specified.
request-header-name: request-header-value1, request-header-value2, ...
Examples of request headers are:
Host: www.xyz.com
Connection: Keep-Alive
Accept: image/gif, image/jpeg, */*
Accept-Language: us-en, fr, cn
The first thing you’ll find is an HTTP method name. The method name tells the server the kind of request
that’s being made, and how the rest of the message will be formatted. The HTTP protocol has several
methods, but the ones you’ll use most often are GET and POST.
*** GET is a simple request, POST can send user data
GET is the simplest HTTP method, and its main job in life is to ask the server to get a resource and send it
back. That resource might be an HTML page, a JPEG, a PDF, etc. Doesn’t matter. The point of GET is to get
something back from the server.
POST is a more powerful request. It’s like a GET plus plus. With POST, you can request something and at
the same time send form data to the server (later we’ll see what the server might do with that data).
*** Those are the two big ones that everybody uses. But there are a few rarely used methods like HEAD,
TRACE, PUT, DELETE, OPTIONS, and CONNECT. We will discuss those later.
It’s true... you can send a little data with HTTP GET. Reasons you might use POST instead of GET include:
1. The total amount of characters in a GET is really limited (depending on the server). If the user
types, say, a long passage into a “search” input box, the GET might not work.
2. The data you send with the GET is appended to the URL up in the browser bar, so whatever you
send is exposed. Better not put a password or some other sensitive data as part of a GET!
Now that we’ve seen the requests from the browser to the server, let’s look at what the server sends back
in response. An HTTP response has both a header and a body. The header info tells the browser about the
protocol being used, whether the request was successful, and what kind of content is included in the
body. The body contains the contents (for example, HTML) for the browser to display.
1. The first line is called the status line, followed by optional response header(s). The status line has
the following syntax:
HTTP-version status-code reason-phrase
HTTP-version: The HTTP version used in this session. Either HTTP/1.0, HTTP/1.1 and HTTP/2.0.
status-code: a 3-digit number generated by the server to reflect the outcome of the request.
reason-phrase: gives a short explanation to the status code.
*** Common status code and reason phrase are "200 OK", "404 Not Found", "403 Forbidden", "500
Internal Server Error".
Examples of status line are:
HTTP/1.1 200 OK
HTTP/1.0 404 Not Found
HTTP/1.1 403 Forbidden
2. Response Headers: The response headers are in the form name:value pairs:
response-header-name: response-header-value1, response-header-value2, ...
Examples of response headers are:
Content-Type: text/html
Content-Length: 35
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
3. The response message body contains the resource data requested.
Uniform Resource Locators, that you know and love --- Every resource on the web has its own unique
address, in the URL format.
A URL (Uniform Resource Locator) is used to uniquely identify a resource over the web. URL has the
following syntax:
protocol://hostname:port/path-and-file-name
Hostname: The DNS domain name (e.g., www.nowhere123.com) or IP address (e.g., 192.128.1.2) of the
server.
Port: Your internet web (HTTP) server software runs on port 80. That’s a standard. If you’ve got a Telnet
server, it’s running on port 23. FTP? 21. POP3 mail server? 110. SMTP? 25. The Time server sits at 37.
Think of ports as unique identifiers. A port represents a logical connection to a particular piece of
software running on the server hardware. That’s it. You can’t spin your hardware box around and find a
TCP port. For one thing, you have 65536 of them on a server (0 to 65535). For another, they do not
represent a place to plug in physical devices. They’re just numbers representing a server application.
Without port numbers, the server would have no way of knowing which application a client wanted to
connect to. And since each application might have its own unique protocol, think of the trouble you’d
have without these identifiers. What if your web browser, for example, landed at the POP3 mail server
instead of the HTTP server? The mail server won’t know how to parse an HTTP request! And even if it
did, the POP3 server doesn’t know anything about serving back an HTML page. If you’re writing services
(server programs) to run on a company network, you should check with the sys-admins to find out which
ports are already taken. Your sys-admins might tell you, for example, that you can’t use any port number
below, say, 3000.
Web Server --- A web server is a computer system that processes requests via HTTP, the basic network
protocol used to distribute information on the World Wide Web. The term can refer to the entire system,
or specifically to the software that accepts and supervises the HTTP requests. The Apache HTTP Server,
also known as Apache is free and open-source (it is free and provides the rights to study, change, and
distribute the software to anyone and for any purpose ) cross-platform (Can be installed or used on any
OS --- Unix, Windows, Mac) web server software.
We’ll talk more about Apache and Tomcat later, but for now let’s assume that our simple web site
is using Apache (the extremely popular, open source web server you’re probably already using). What
would the directory structure look like for a web site called www.wickedlysmart.com, hosting two
applications, one giving skiing advice, and the other beer-related advice? Imagine that the Apache
application is running on port 80. The .html pages are each marked with a letter (A, B, C, D).
Mapping URLs to content
Look at the directory structure on the opposite page, then write in a URL that would get you to each of
the four .html pages marked with the A, B, C, and D. We did the first one (A) for you.
Web pages are those with content that cannot be changed without the developer who developed the
webpage, editing its source code, while dynamic Web pages can display different content from the same
source code.
Web servers love serving static web pages --- A static page just sits there in a directory. The server finds it
and hands it back to the client as is. webpage in which all the information and material is presented
before users as it is exactly stored. Every client/user sees the same thing.
*** Static --- meaning fixed
*** Dynamic --- changing.
which each time shows different content and materials to the user whenever visited. It randomly
changes according to time.
But sometimes you need more than just the web server
Using CGI, here’s how it might work for a dynamic web page that has the current server date.
There are many problems in CGI technology:
1. If number of clients increases, it takes more time for sending response.
2. For each request, it starts a process and Web server is limited to start processes.
3. It uses platform dependent language e.g. C, C++, perl. (Platform dependent --- can run in different
operating environments)