Module - I

What is Web Architecture?

Web architecture refers to the overall structure of a website or web application, including the
way it is designed, implemented, and deployed. It involves the use of technologies and
protocols such as HTML, CSS, JavaScript, and HTTP to build and deliver web pages and
applications to users.

Web architecture consists of several components, including the client, the server, the
network, and the database. The client is the web browser or application that the user
interacts with, and the server is the computer or group of computers that host the website or
web application. The network is the infrastructure that connects the client and the server,
such as the internet. The database is a collection of data that is used to store and retrieve
information for the website or web application.

Web architecture also includes the design and layout of the website or web application, as
well as the way it is organized and the relationships between different pages and
components. It also includes the way the website or web application is built and maintained,
including the use of frameworks and libraries, and the deployment and hosting of the
website or web application.

Web Architecture Components

The client −This is the web browser or application that the user interacts with. The client
sends requests to the server and receives responses from the server.

The server −This is the computer or group of computers that host the website or web
application. The server processes requests from the client and sends back the appropriate
response.

The network This is the infrastructure that connects the client and the server, such as the
internet. It allows for communication between the client and the server.

The database −This is a collection of data that is used to store and retrieve information
for the website or web application. The database can be located on the same server as the
website or web application, or it can be hosted on a separate server.

The design and layout −This refers to the way the website or web application is
structured and organized, including the layout, navigation, and overall appearance.

The frameworks and libraries − These are tools and resources that are used to
build and maintain the website or web application. They can include frameworks like Ruby
on Rails or Django, or libraries like jQuery or React.

The deployment and hosting − This refers to the way the website or web
application is deployed and hosted, including the hosting environment (such as a shared
hosting plan or a cloud platform) and the process for deploying updates and changes to the

Why is Web Architecture Important?

Web architecture is important because it plays a crucial role in the performance, scalability,
and maintenance of a website or web application.

A well-designed web architecture can improve the user experience by ensuring that the
website or web application loads quickly and reliably. It can also make the website or web
application easier to maintain, as it provides a clear structure and organization that makes it
easier to find and modify different components.

Web architecture is also important for scalability, as it determines the website or web
application's ability to handle increasing traffic and usage without experiencing performance
issues. A scalable web architecture can support growth and handle changes in traffic
patterns without requiring major changes to the system.

Finally, a strong web architecture can improve the security of a website or web application
by implementing

How Web Works – Web Application Architecture for

Beginners
For many decades we are browsing our favorite websites on the internet and getting a quick
response whatever we want… but do you ever try to know how each part of the application
works together and how is the request being processed behind the scene? If you’re a little
bit familiar with tech then you may have a general and a common answer that your request
goes to the web server, then the webserver processes the request and perform all the
backend logic. After that, it sends the response back to the web browser and then you see
the result in front of your screen.

Well, that’s exactly true but if you go on a deeper level, you’ll find that your web application
has a complex architecture of different components and layers. Your request passes
through these different layers and components and then you get the response back from
the server’s end. It’s a quite long process but understanding the fundamental of web
application architecture is really important if your goal is to become a good web application
developer. Firstly let’s understand a few things about web applications.

When you’re building an application, you need to remember three principles in your mind…
From the customer’s point of view, the application shouldn’t be complicated, it should be
pleasing, and it should address most of their problems.

From a business aspect, your web application should stay aligned with its product/market fit.

From an engineer’s perspective, the application should be scalable, functional, and it should
be able to bear high traffic loads.

We will discuss the above points in web application architecture and we will understand the
core concept, how the architecture works, its components, and types in detail.

What is Web Application Architecture?

Do you know that there is a difference between websites and web applications? (you might
have thought that both are the same). The web application is a program that runs on a
browser and it has mainly three formal characteristics.

Addresses a particular problem, even if it’s simply finding some information As interactive as
a desktop application Works with Content Management System.

If we talk about the website, then traditionally it’s just a combination of static pages. A
website becomes a web application when it consists of both static and dynamic pages (yes!!
it’s true that all modern websites are the example of web applications.)

Web application architecture is a mechanism that gives us a clarification that how the
connection is established between the client and the server. It determines how the
components in an application communicate with each other. It doesn’t matter what is the
size and the complexity level of the application is, they all follow the same principle only the
details may differ.

In technical terms, when a user makes a request on a website, various components of the
applications, user interfaces, middleware systems, databases, servers, and the browser
interact with each other. Web Application Architecture is a framework that ties up this
relation together and maintains the interaction between these components.

When a user interacts with a website and gets the response back from the server’s end, the
whole process executes within a few seconds. The most important thing we need to notice
here is the code which has been passed to the browser. This code may or may not have
particular instructions telling the browser how to respond with respect to the different types
of user inputs. That’s why a web application architecture includes all the sub-components
and external applications interchanges for an entire software application. A web application
architecture has to deal with the reliability, scalability, security, and robustness due to a
large amount of global network traffic.
How Does the Web Request Work?
Let’s take an example that you want to visit Flipkart.com.

You enter flipkart.com in your browser: When you type the URL in your web
browser and hit enter the web browser needs to know the address of the server
where the page is located. So it sends the request to the DNS (Domain Name
Server, which is a storehouse of domain names and their IP addresses). After
that browser sends the request to the found IP address using the HTTPS
protocol. If you already have visited Flipkart.com earlier from the same browser,
then it will pull the address from the cache.

The web server processes the request: In the next step, the webserver sends
the request to the storage area to locate the page and all data that follows with it.
Here the Business logic (also called Domain Logic and Application Logic) comes
in the picture. BL takes the responsibility of routing which means how each piece
of data is accessed. It regulates this workflow specifically for each application. As
BL processes the request, it sends it to storage to locate the looked-for data.

You get the response back: When the response travels back, it displays in front
of your screen. The web page (graphical interface) for any website which is
displayed on your screen is called the front end of an application. Here you see
all the UI and UX components to access the information.

How Does Web Application Architecture Work?

All the web applications run on the client-side and the server-side. When a user
makes a request there are mainly two programs run on both sides.

Code that runs in the browser and works as per the inputs of the user.

Code in the server which responds to the HTTP requests

While working on the web application, a web developer decides the functions of
the code on the server and the functions of the code on the browser. They also
define how these two will function in relation to each other. Server-side code can
be written using the languages Python, JavaScript, C#, PHP, Ruby on Rails, etc.
Any code can have the capability to run on the server if it can respond to HTTP
requests. The server-side code is mainly responsible for creating the page which
the user has requested. It also stores different types of data such as user profiles,
tweets, pages, etc. Server-side code can not be seen by the end-user (except
within a rare malfunction)

Client-side languages include the combination of HTML, CSS, and JavaScript.

This code is parsed by the browser, and it can be seen as well as edited by the
user. Only through HTTP requests, client-side code can communicate with the
server. Also, it cannot read files off a server directly.

Web Application Architecture Components

Web application architecture works on various components. These components
can be divided into two areas.

1. User Interface App Components: As the name suggests this category is

much more related to the user interface/experience. In this category, the role of
the web page is related to the display, dashboards, logs, notifications, statistics,
configuration settings, etc and it has nothing to do with the functionality or
working of the web application.

2. Structural Components: This category is mainly concerned with the

functionality of the web application with which a user interacts, the control, and
the database storage. As the name suggests it is much more about the structural
part of the web application. This structural part comprises…

The web browser or client

The web application server

The database server

Web Application Three Tier Architecture Layers

Web application architectural patterns are separated into many different layers or
tiers which is called Multi- or Three-Tier Architecture. You can easily replace and
upgrade each layer independently.

Presentation Layer: This layer is accessible to the client via a browser and it
includes user interface components and UI process components. As we have
already discussed that these UI components are built with HTML, CSS, and
JavaScript (and its frameworks or library) where each of them plays a different
role in building the user interface.

Business Layer: It is also referred to as a Business Logic or Domain Logic or

Application Layer. It accepts the user’s request from the browser, processes it,
and regulates the routes through which the data will be accessed. The whole
workflow is encoded in this layer. You can take the example of booking a hotel on
a website. A traveler will go through a sequence of events to book the hotel room
and the whole workflow will be taken care of by the business logic.

Persistence Layer: It is also referred to as a storage or data access layer. This

layer collects all the data calls and provides access to the persistent storage of
an application. The business layer is closely attached to the persistence layer, so
the logic knows which database to talk to and the process of retrieving data
becomes more optimized. A server and a database management system
software exist in data storage infrastructure which is used to communicate with
the database itself, applications, and user interfaces to retrieve data and parse it.
You can store the data in hardware servers or in the cloud.

Some other parts of the web application which is separated from the main layers
that exist in the architecture are…

Cross-cutting code: This part handles communications, operational

management, and security. It affects all parts of the system but should never mix
with them.

Third-party integrations: Using third-party APIs we can integrate payment

gateways, social logins, GDSs in travel websites, etc.

Types of Web Application Architecture

1. Single Page Applications: Today a lot of modern web applications are
designed as single-page web applications that only include the most required
elements and information to generate an intuitive and interactive user experience.
In a single page application, the content or information is updated on the current
page rather than loading a new page from the server for each action performed
by the user.

The application requests only necessary content details and it prevents

interruptions in the user experience.

AJAX, Asynchronous JavaScript, and XML are mainly used for page
communication.

Users can continue the interaction with the page while the contents are updated
on the page (faster interaction).

2. Microservices: These are small and lightweight services that execute specific,
single functionality. The components in the applications are not dependent on
each other, so there is no need to develop each component using the same
programming language. This gives the flexibility to the developers to choose the
language or technology stack of their own choice. It enhances the productivity of
the developers and speeds up the development process.

3. Serverless Architectures: In this approach, developers outsource the server

and infrastructure management from a third-party cloud infrastructure services
provider. The advantage of this approach is that it allows the application to
execute the required or custom logic without worrying about the infrastructure-
related tasks. This approach is mainly preferred by the companies who don’t
want to manage or support the servers and the hardware they have developed
the web application for.

Difference HTTP1.0 and HTTP 1.1

1. Introduction
From an engineering point of view, networks typically consider the OSI model or the TCP/IP
model to define and organize their operation. These models, in turn, contemplate different layers,
such as the network layer, the transport layer, and the application layer.

Each network layer has particular protocols that implement a myriad of functionalities. Examples
are the IP at the network layer, TCP and UDP at the transport layer, and HTTP at the
application layer.

These protocols evolve, thus being updated and extended over time. So, it is natural that
network protocols have multiple versions.

In this context, this tutorial holistically explores the HTTP application protocol. First, we’ll have a
brief review of application protocols. Thus, we’ll study the general purposes of HTTP. Finally,
we’ll see the main differences among the HTTP versions and compare them in a systematic
summary.

Application Layer Protocols

Application layer protocols refer to an abstract network layer providing end-to-end

communication between different computational applications. It is the 7th layer of the OSI model
and the 4th layer of the TCP/IP model.

In practice, the application layer is the closest layer to the user. So, it is in the application layer
that, for example, clients of e-mail, streams, and browsers operate.

Furthermore, there are three principals architectures employed to build application-layer

systems:

Client-Server: the main characteristic of the client-server architecture is to have multiple clients
requesting and receiving services from a centralized server

Peer-to-Peer: the peer-to-peer architecture considers a collection of independent computers

connected in the network that collaborate to execute an operation

Hybrid: an architecture that employs both servers and peers to execute operations

Naturally, the application layer uses the functionalities of the lower layers. For example,
application protocols assume that other layers tackle the communication with the correct
destination computer connected in the network.

Finally, some examples of popular application layer protocols are HTTP, FTP, TELNET, POP,
DNS, and SMTP.
The Hypertext Transfer Protocol
HTTP is an application protocol (layer 7 OSI and layer 4 TCP/IP) employed
to create distributed hypermedia systems. Since it operates on the application layer,
it is agnostic of several networking aspects, such as addressing and transmission.

Historically, HTTP emerged as a simple protocol to enable communication between clients and
servers over the Internet. From its release, HTTP became one of the most relevant protocols to
exchange information on the World Wide Web.

In this way, HTTP has been used on the Internet since the ’90s. The first release of HTTP (0.9)
was much limited. This version only enabled clients to request information from a server using a
single operation: GET.

The first HTTP release only supported transmitting ASCII data. However, in the following
releases, this support expanded to other data types.

HTTP relies on TCP/IP to work. It means that HTTP is a connection-based protocol. In

such a way, we can understand an HTTP session as a sequence of message exchanges
between a server connected to a client.

In the following subsections, we’ll explore each released version of HTTP, from 1.0 to 3.0,
focusing on their particular characteristics and novelty compared to the previously released
version.

HTTP Version 1.0

As previously presented, the first version of HTTP only allowed getting information from a server.
However, it became insufficient as the Internet evolved and new functionalities arose.

In this context, version 1.0 of HTTP was released in 1996, about five years
after version 0.9.

Version 1.0 of HTTP brings several new utilities. Let’s see some of them:

Header: only the method and the resource name composed an HTTP 0.9 request. HTTP 1.0,
in turn, introduced the HTTP header, thus allowing the transmission of metadata that made the
protocol flexible and extensible

Versioning: the HTTP requests explicitly informs the employed version, appending it in the
request line

Status code: HTTP responses now contain a status code, thus enabling the receiver to check
the request processing status (successful or failed)

Content-type: thanks to the HTTP header, in specific to the Content-Type field, HTTP can
transmit other documents types than a plain HTML file

New methods: besides GET, HTTP 1.0 provides two new methods (POST and HEAD)

In summary, HTTP 1.0 got much more robust than the 0.9 version. The most
responsible for the protocol improvements are the HTTP header and the new HTTP methods.

So, the HTTP header enabled clients to send and receive different file types and exchange
relevant metadata. The new methods, in turn, enabled the clients to both recover only the
metadata about a document (HEAD) and transfer data from the client to the server (POST).

HTTP Version 1.1

Version 1.1 of HTTP was released in 1997, only one year after the previous
version 1.0. HTTP 1.1 is an enhancement of HTTP 1.0, providing several extensions.

Among the most relevant enhancements, we can cite the following:

Host header: HTTP 1.0 does not officially require the host header. HTTP 1.1 requires it by
the specification. The host header is specially important to route messages through proxy
servers, allowing to distinguish domains that point to the same IP

Persistent connections: in HTTP 1.0, each request/response pair requires opening a new
connection. In HTTP 1.1, it is possible to execute several requests using a single connection

Continue status: to avoid servers refusing un processable requests, now clients can first
send only the request headers and check if they receive a continue status code (100)

New methods: besides the already available methods of HTTP 1.0, the 1.1 version added
six extra methods: PUT, PATCH, DELETE, CONNECT, TRACE, and OPTIONS

In addition to the highlighted enhancements, there are many others introduced in version 1.1 of
HTTP, such as compression and decompression, multi-language support, and byte-range
transfers.

Specifically, the new methods represented a real improvement in using

HTTP. The PUT methods got in charge of replacing already existing resources. The PATCH
method updates particular data of an already existing resource. On the other hand, DELETE
removes an already existing resource.

The HTTP CONNECT can create a tunnel through a proxy server. TRACE executes a loopback
test in the path from a client to the destination server. Finally, OPTIONS returns information
about the available communications options with the server.
Stateless nature of the protocol
As HTTP is a stateless then how to maintain the session between web browser and web
server?

HTTP is a "stateless" protocol which means each time a client retrieves a Webpage, the client
opens a separate connection to the Web server and the server automatically does not keep any
record of previous client request.

Cookies
A webserver can assign a unique session ID as a cookie to each web client and for subsequent
requests from the client they can be recognized using the received cookie.

This may not be an effective way as the browser at times does not support a cookie. It is not
recommended to use this procedure to maintain the sessions.

Hidden Form Fields

A web server can send a hidden HTML form field along with a unique session ID as follows −

<input type = "hidden" name = "sessionid" value = "12345">

This entry means that, when the form is submitted, the specified name and value are
automatically included in the GET or the POST data. Each time the web browser sends the
request back, the session_id value can be used to keep the track of different web browsers.

This can be an effective way of keeping track of the session but clicking on a regular (<A
HREF...>) hypertext link does not result in a form submission, so hidden form fields also cannot
support general session tracking.

URL Rewriting
You can append some extra data at the end of each URL. This data identifies the session; the
server can associate that session identifier with the data it has stored about that session.

For example, with http://tutorialspoint.com/file.htm;sessionid=12345, the session identifier is

attached as session id = 12345 which can be accessed at the web server to identify the client.

URL rewriting is a better way to maintain sessions and works for the browsers when they don't
support cookies. The drawback here is that you will have to generate every URL dynamically to
assign a session ID though page is a simple static HTML page.
HTTP Request Methods (GET, POST, HEAD, PUT, DELETE)
What is HTTP?
The Hypertext Transfer Protocol (HTTP) is designed to enable communications between clients
and servers. HTTP works as a request-response protocol between a client and server.
Example: A client (browser) sends an HTTP request to the server; then the server returns a
response to the client. The response contains status information about the request and may
also contain the requested content. The HTTP Methods is as follows:
➢ GET
➢ POST
➢ PUT
➢ HEAD
➢ DELETE
➢ PATCH
➢ OPTIONS
➢ CONNECT
➢ TRACE
The two most common HTTP methods are: GET and POST.

The GET Method

GET is used to request data from a specified resource.
Note that the query string (name/value pairs) is sent in the URL of a GET request:
/test/demo_form.php?name1=value1&name2=value2
Some notes on GET requests:
➢ GET requests can be cached
➢ GET requests remain in the browser history
➢ GET requests can be bookmarked
➢ GET requests should never be used when dealing with sensitive data
➢ GET requests have length restrictions
➢ GET requests are only used to request data (not modify)

The POST Method

POST is used to send data to a server to create/update a resource.
The data sent to the server with POST is stored in the request body of the HTTP request:
POST /test/demo_form.php HTTP/1.1
Host: cutm.ac.in
name1=value1&name2=value2
Some notes on POST requests:
➢ POST requests are never cached
➢ POST requests do not remain in the browser history
➢ POST requests cannot be bookmarked
➢ POST requests have no restrictions on data length

Compare GET vs. POST

The following table compares the two HTTP methods: GET and POST.
GET POST
Data will be re-submitted (the
BACK browser should alert the user that
Harmless
button/Reload the data are about to be re-
submitted)
Bookmarked Can be bookmarked Cannot be bookmarked
Cached Can be cached Not cached
application/x-www-form-urlencoded
Encoding type application/x-www-form-urlencoded or multipart/form-data. Use
multipart encoding for binary data
Parameters are not saved in
History Parameters remain in browser history
browser history
Yes, when sending data, the GET method
Restrictions on adds the data to the URL; and the length
No restrictions
data length of a URL is limited (maximum URL length
is 2048 characters)
Restrictions on No restrictions. Binary data is also
Only ASCII characters allowed
data type allowed
GET is less secure compared to POST
POST is a little safer than GET
because data sent is part of the URL
because the parameters are not
Security
stored in browser history or in web
Never use GET when sending passwords
server logs
or other sensitive information!
Visibility Data is visible to everyone in the URL Data is not displayed in the URL

The PUT Method

PUT is used to send data to a server to create/update a resource.
The difference between POST and PUT is that PUT requests are idempotent. That is, calling the
same PUT request multiple times will always produce the same result. In contrast, calling a
POST request repeatedly have side effects of creating the same resource multiple times.

The HEAD Method

HEAD is almost identical to GET, but without the response body.
In other words, if GET /users returns a list of users, then HEAD /users will make the same
request but will not return the list of users.
A HEAD request is useful for checking what a GET request will return before actually making a
GET request - a HEAD request can read the Content-Length header to check the size of the file,
without actually downloading the file.

The DELETE Method

The DELETE method deletes the specified resource.

The PATCH Method

The PATCH method is used to apply partial modifications to a resource.

The OPTIONS Method

The OPTIONS method describes the communication options for the target resource.

The CONNECT Method

The CONNECT method is used to start a two-way communication (a tunnel) with the requested
resource.

The TRACE Method

The TRACE method is used to perform a message loop-back test that tests the path for the
target resource (useful for debugging purposes).
HTTP session
An HTTP session is a temporary information exchange between a server and a client. It is a
sequence of network request-response transactions that are initiated by the client using TCP or
an alternative protocol on a specific port. Typically, HTTP Sessions are created using port 80 or
8080. If a secure, encrypted session is created using HTTPS, then the default connection is
made using port 443.

Status codes
HTTP status codes are three-digit responses from the server to the browser-side request. Eve-
ryone has probably gotten the classic 404 page-not-found error. That is an HTTP client error
status code and there are a lot more of them.

These status codes (also called response status codes) serve as a means of communication
between the server and the internet browser and there are multiple code classes based on the
type of information they are communicating. The differences in classes are indicated through the
first digit of the error code, for example: just like a 404, any other 4xx will mean that in some
way the page or website could not be reached, while a 2xx means that your request was suc-
cessfully completed.

How are HTTP status codes categorized?

HTTP status codes are split into 5 different categories. Each category will give you hints as to
what the response was, even if you don't know the specific response code. For an explanation
of each category - and each individual status code - click on the corresponding link below or go
to our complete list of HTTP status codes.
➢ 1xx - Informational: The server has received the request and is continuing the process
➢ 2xx - Successful: The request was successful, and the browser has received the ex-
pected information
➢ 3xx (Redirection): You have been redirected and the completion of the request requires
further action
➢ 4xx (Client Error): The website or the page could not be reached, either the page is una-
vailable, or the request contains bad syntax
➢ 5xx (Server Error): While the request appears to be valid, the server could not complete
the request
Complete list of HTTP Status Codes
Status code Meaning
1xx Informational
100 Continue
101 Switching protocols
102 Processing
103 Early Hints

2xx Succesful
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

3xx Redirection

300 Multiple Choices

301 Moved Permanently
302 Found (Previously "Moved Temporarily")
303 See Other
304 Not Modified
305 Use Proxy
306 Switch Proxy
307 Temporary Redirect
308 Permanent Redirect

4xx Client Error

400 Bad Request

401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 URI Too Long
415 Unsupported Media Type
416 Range Not Satisfiable
417 Expectation Failed
418 I'm a Teapot
421 Misdirected Request
422 Processable Entity
423 Locked
424 Failed Dependency
425 Too Early
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
451 Unavailable For Legal Reasons

5xx Server Error

500 Internal Server Error

501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required

HTTP Status Codes explained individually

What does a 1xx Informational status code mean?

A 1xx Informational status code means that the server has received the request and is continu-
ing the process. A 1xx status code is purely temporary and is given while the request processing
continues. For most tasks you won't encounter these much, as it's not the final response to the
request.
• 100 Continue
• 101 Switching protocols
• 102 Processing
• 103 Early Hints

What does a 2xx Successful status code mean?

A 2xx Successful status code means that the request was successful, and the browser has re-
ceived the expected information. This is generally the one you want to see, as it means that the
request was a success and has been received, understood and accepted it. As a website owner
you should make sure that all pages and resources (images, videos, etc.) all return a 2xx status
code. This means that browsers can reach it successfully and that your website visitors can see
and use your website.
 • 200 OK
• 201 Created
• 202 Accepted
• 203 Non-Authoritative Information
• 204 No Content
• 205 Reset Content
• 206 Partial Content
• 207 Multi-Status
• 208 Already Reported
• 226 IM Used

What does a 3xx Redirection code mean?

A 3xx Redirection status code means that you have been redirected and the completion of the
request requires further action. Redirects are a natural part of the internet and you shouldn't be
scared to have 3xx redirect status codes on your website. A redirect means that the request was
received successfully, but that the resource was found elsewhere. If a webpage has changed
path and you try to access it through the old path, your CMS will often redirect the user to the
new path. Ultimately the request will end in a 2xx success, but first it must go through the 3xx
redirection.
• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found (Previously "Moved temporarily")
• 303 See Other
• 304 Not Modified
• 305 Use Proxy
• 306 Switch Proxy
• 307 Temporary Redirect
• 308 Permanent Redirect

What does a 4xx Client Error mean?

A 4xx Client Error status code means that the website or the page could not be reached and
either the page is unavailable, or the request contains bad syntax. As a website owner you
should do your best to avoid these, as it means your users will not find what they're looking for.
This can be either pages that are no longer found and are either temporarily or permanently
gone. Besides giving a bad user experience, it can also hurt your SEO efforts.
• 400 Bad Request
• 401 Unauthorized
• 402 Payment Required
• 403 Forbidden
• 404 Not Found
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required
• 408 Request Timeout
• 409 Conflict
• 410 Gone
• 411 Length Required
• 412 Precondition Failed
 • 413 Payload Too Large
• 414 URI Too Long
• 415 Unsupported Media Type
• 416 Range Not Satisfiable
• 417 Expectation Failed
• 418 I'm a Teapot
• 421 Misdirected Request
• 422 Unprocessable Entity
• 423 Locked
• 424 Failed Dependency
• 425 Too Early
• 426 Upgrade Required
• 428 Precondition Required
• 429 Too Many Requests
• 431 Request Header Fields Too Large
• 451 Unavailable for Legal Reasons

What is a persistent connection?

A persistent connection, also known as a Hypertext Transfer Protocol (HTTP) persistent connec-
tion, refers to a network communication channel that remains open for further HTTP requests
and responses instead of closing after a single exchange. Persistent connections are also called
HTTP keep-alive and HTTP connection reuse.
An example of where a persistent connection is important can be found in an internet user's re-
quest to open a webpage. Accessing the page requires multiple content elements to be down-
loaded, including images, text and scripts. Without a persistent connection, each of those ele-
ments would require a new connection to the web server, leading to delays in displaying the full
page. With the system providing a persistent connection, the download is accelerated.

Persistent connection function in HTTP

HTTP is an application-level protocol that typically runs on port 80. It uses Transmission Control
Protocol (TCP) as an underlying transport protocol. TCP is a connection-oriented protocol: It
starts a connection after confirmation from both ends that they are available and open to a data
exchange.
A persistent connection function in HTTP 1.1, introduced in 1997, and later versions allowed the
channel to remain open rather than closing after a requested exchange of data. The goal is to
use a single TCP connection to send multiple HTTP requests and receive multiple HTTP re-
sponses, instead of opening a new connection for every request-response pair.
In early web technology based on HTTP 1.0, the server always closed connections after send-
ing the response. Persistent connections added to this protocol used an extra header to request
the client keep the connection alive. HTTP 1.1 assumes all connections to be persistent unless
otherwise specified. In other words, persistent connections are the default behavior of any con-
nection in HTTP 1.1. The HTTP/2 protocol expands the idea to enable multiple requests and
returns of data to be exchanged simultaneously, or multiplexed, over a single connection.
A persistent connection is a network communication channel that stays open for additional
HTTP requests and responses instead of closing after an exchange.

Persistent connections vs. nonpersistent connections

The difference between persistent and nonpersistent connections becomes most obvious in
terms of round-trip time (RTT). RTT is the duration in milliseconds from when a web brows-
er first sends a request to when it receives a response from a web server. As a key performance
metric for web applications, a lower RTT is always desirable. The RTT value is two times the
value of the packet propagation time.
In persistent connections, the server leaves the connection open after sending a response. TCP
keep-alive packets are sent to maintain the connection and prevent it from timing out. Subse-
quent HTTP messages between the server and clients are sent over this open connection. Fur-
ther, the client sends a request to the server as soon as it encounters a referenced object -- for
example, an image or text file. All of this reduces the RTT.
In a nonpersistent connection, the channel closes when one host signals that it wants to end
communications or when a certain amount of time has elapsed with no exchange of data. There
is some additional overhead for each TCP connection, so the RTT is higher. In addition, brows-
ers often open parallel TCP connections to fetch referenced objects. This again increases the
RTT and introduces latency into the network.

Benefits of persistent connections

An open and persistent connection is faster for frequent data exchanges. A connection that
stays open rather than opening and closing sessions for each request also saves communica-
tions overhead. Persistent connections can be used with application programming interfaces to
enable servers to push data to clients.
Other benefits of persistent connections include the following:
• reduced network congestion due to fewer TCP connections and lower network traffic;
• lower latency for subsequent requests because the initial TCP handshake is avoided;
• less processor and memory usage due to the lower number of connections and few-
er Secure Socket Layer/Transport Layer Security handshakes; and
 • support for HTTP pipelining of both requests and responses.
In addition, transmission errors can be reported without closing the persistent connection. And
with long-lasting connections, the TCP gets sufficient time to determine the network's conges-
tion state and then react appropriately.

Drawbacks of persistent connections

One drawback of a persistent connection is that if one client does not close the connection after
receiving all its required data, other clients will be unable to access the resources needed to
keep the connection open on the server. This can affect resource and server availability for
these clients. The period of unavailability depends on the server's architecture and configuration.
Another problem is that when a client sends a request to the server at the same time that the
server closes the TCP connection, it can result in what is known as a race condition. To avoid
this issue, the server should send a "408 Request Timeout" status code to the client before clos-
ing the connection. On receiving this code, the client can open a new connection to the server
and resend the request. However, not all clients will resend the request, leading to unexpected
or undesirable results.
If proxy servers are in place, they must correctly signal all persistent or nonpersistent connec-
tions separately with all clients, origin servers and other proxy servers. This is because persis-
tent connections apply to only one transport link.

Persistent connections for webpage requests

Persistent connections are frequently used for webpage requests. First, the web browser re-
quests the page, parses it and identifies the resources -- such as images, cascading style
sheets and scripts -- it will need to render that page. Since the browser requests these re-
sources one by one, it is most efficient to maintain a persistent connection, which reduces the
overhead and associated delays when new connections are created and destroyed.
From the perspective of the web server, a persistent connection allows the server to push con-
tent to the client's web browser. The webpage requests many different resources on the same
server. When the server doesn't close the socket after it finishes pushing out one response, but
instead reuses it for further requests, the browser can make other requests on the same socket,
thus reducing the overall latency. The latency would be much higher if the original socket was
closed and a new socket had to be opened for every follow-on request from the browser.

Persistent connections in web browsers

All modern web browsers such as Google Chrome, Mozilla Firefox and Microsoft Edge use per-
sistent connections. However, these connections typically time out after a predefined period of
inactivity. For most browsers, the timeout period can be modified from the Windows Registry.
For example, in Edge, this period is 1 minute. The browser will reuse the same TCP/IP socket
that was used for the initial request until the socket is idle for 1 minute. After the minute has
passed, it will reset the connection for additional requests, and a new TCP/IP socket will be
used.

What is HTTPS?
Hypertext transfer protocol secure (HTTPS) is the secure version of HTTP, which is the primary
protocol used to send data between a web browser and a website. HTTPS is encrypted in order
to increase security of data transfer. This is particularly important when users transmit sensitive
data, such as by logging into a bank account, email service, or health insurance provider.
Any website, especially those that require login credentials, should use HTTPS. In modern web
browsers such as Chrome, websites that do not use HTTPS are marked differently than those
that are. Look for a padlock in the URL bar to signify the webpage is secure. Web browsers take
HTTPS seriously; Google Chrome and other browsers flag all non-HTTPS websites as not se-
cure.

How does HTTPS work?

HTTPS uses an encryption protocol to encrypt communications. The protocol is called Transport
Layer Security (TLS), although formerly it was known as Secure Sockets Layer (SSL). This pro-
tocol secures communications by using what’s known as an asymmetric public key infrastruc-
ture. This type of security system uses two different keys to encrypt communications between
two parties:
• The private key - this key is controlled by the owner of a website and it’s kept, as the
reader may have speculated, private. This key lives on a web server and is used to de-
crypt information encrypted by the public key.
• The public key - this key is available to everyone who wants to interact with the server in
a way that’s secure. Information that’s encrypted by the public key can only be decrypted
by the private key.

Why is HTTPS important? What happens if a website

doesn’t have HTTPS?
HTTPS prevents websites from having their information broadcast in a way that’s easily viewed
by anyone snooping on the network. When information is sent over regular HTTP, the infor-
mation is broken into packets of data that can be easily “sniffed” using free software. This
makes communication over the an unsecure medium, such as public Wi-Fi, highly vulnerable to
interception. In fact, all communications that occur over HTTP occur in plain text, making them
highly accessible to anyone with the correct tools, and vulnerable to on-path attacks.

With HTTPS, traffic is encrypted such that even if the packets are sniffed or otherwise intercept-
ed, they will come across as nonsensical characters. Let’s look at an example:

Before encryption:
This is a string of text that is completely readable
After encryption:
ITM0IRyiEhVpa6VnKyExMiEgNveroyWBPlgGyfkflYjDaaFf/Kn3bo3OfghBPDWo6AfSHlNtL8
N7ITEwIXc1gU5X73xMsJormzzXlwOyrCs+9XCPk63Y+z0=

In websites without HTTPS, it is possible for Internet service providers (ISPs) or other interme-
diaries to inject content into webpages without the approval of the website owner. This common-
ly takes the form of advertising, where an ISP looking to increase revenue injects paid advertis-
ing into the webpages of their customers. Unsurprisingly, when this occurs, the profits for the
advertisements and the quality control of those advertisements are in no way shared with the
website owner. HTTPS eliminates the ability of unmoderated third parties to inject advertising
into web content.

What port does HTTPS use?

HTTPS uses port 443. This differentiates HTTPS from HTTP, which uses port 80.

(In networking, a port is a virtual software-based point where network connections start and end.
All network-connected computers expose a number of ports to enable them to receive traffic.
Each port is associated with a specific process or service, and different protocols use different
ports.)

How else is HTTPS different from HTTP?

Technically speaking, HTTPS is not a separate protocol from HTTP. It is simply using TLS/SSL
encryption over the HTTP protocol. HTTPS occurs based upon the transmission of TLS/SSL
certificates, which verify that a particular provider is who they say they are.

When a user connects to a webpage, the webpage will send over its SSL certificate which con-
tains the public key necessary to start the secure session. The two computers, the client and the
server, then go through a process called an SSL/TLS handshake, which is a series of back-and-
forth communications used to establish a secure connection. To take a deeper dive into encryp-
tion and the SSL/TLS handshake, read about what happens in a TLS handshake.

How does a website start use HTTPS?

Many website hosting providers and other services will offer TLS/SSL certificates for a fee.
These certificates will be often be shared amongst many customers. More expensive certificates
are available which can be individually registered to particular web properties.

All websites using Cloudflare receive HTTPS for free using a shared certificate (the technical
term for this is a multi-domain SSL certificate). Setting up a free account will guarantee a web
property receives continually updated HTTPS protection. You can also explore our paid plans
for individual certificates and other features. In either case, a web property receives all the
benefits of using HTTPS.

HTML Document Object Model (DOM)

Document Object Model

The document object represents the whole html document. When html document is loaded in
the browser, it becomes a document object. It is the root element that represents the html
document. It has properties and methods. By the help of document object, we can add dynamic
content to our web page. As mentioned earlier, it is the object of window. So, window.
document Is same as document According to W3C - "The W3C Document Object Model (DOM)
is a platform and language-neutral interface that allows programs and scripts to dynamically
access and update the content, structure, and style of a document."

Properties of document object

Let's see the properties of document object that can be accessed and modified by the document
object.

Methods of document object

We can access and change the contents of document by its methods.
The important methods of document object are as follows:
 Method
write("string")
writeln("string")
getElementById()
getElementsByName()
Description
writes the given string on the doucment.
writes the given string on the doucment with newline character at
the end.
returns the element having the given id value.
returns all the elements having the given name value.

getElementsByTagName() returns all the elements having the given tag name.
getElementsByClassName() returns all the elements having the given class name.

Accessing field value by document object

In this example, we are going to get the value of input text by user. Here, we are
using document.form1.name.value to get the value of name field.
Here, document is the root element that represents the html document.

form1 is the name of the form.

name is the attribute name of the input text.
value is the property, that returns the value of the input text.
Let's see the simple example of document object that prints name with welcome message.
<script type="text/javascript">
function printvalue(){
var name=document.form1.name.value;
alert("Welcome: "+name);
}
</script>

<form name="form1">
Enter Name:<input type="text" name="name"/>
<input type="button" onclick="printvalue()" value="print name"/>
</form>

What is an Element in HTML.

What do you mean by HTML elements?
An HTML element is a component of an HTML document that tells a web browser how to
structure and interpret a part of the HTML document. HTML elements can contain formatting
instructions, semantic meaning, and content.

Events
HTML has the ability to let events trigger actions in a browser, like starting a JavaScript when a
user clicks on an element. To learn more about programming events, please visit our JavaScript
tutorial. Below are the global event attributes that can be added to HTML elements to define
event actions.