Web Technology Foundations

Introduction

Modern web applications support communication, commerce, education, public services, entertainment, and collaboration. Although a web page may appear to be a single visual document, it is produced through the cooperation of many technologies: networks, browsers, servers, naming systems, communication protocols, programming languages, and technical standards.

For a full-stack programmer, these foundations are essential. HTML describes structure, CSS controls presentation, and JavaScript adds behaviour, but all three operate within a broader web platform. A developer must understand where a request goes, how a server is identified, how a response is returned, why HTTPS matters, and how static and dynamic content differ.

This chapter introduces the principal concepts that make the Web possible and establishes vocabulary used throughout web development.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish the Internet from the World Wide Web;
• explain client–server architecture and the role of browsers and web servers;
• interpret the main components of a URL;
• describe DNS name resolution;
• explain HTTP and HTTPS request–response processing;
• identify the purpose of web standards;
• distinguish static from dynamic websites;
• trace a simple browser request from user action to rendered page; and
• evaluate basic performance, security, accessibility, and governance considerations.

The Internet and the World Wide Web

The Internet is a global interconnection of computer networks. It includes physical and wireless links, routers, data centres, home networks, mobile networks, and protocols that allow devices to exchange data. The Internet is infrastructure and a communication system; it is not one single application.

The World Wide Web, commonly called the Web, is a distributed information system that operates over the Internet. It uses technologies such as URLs, HTTP, HTML, browsers, and web servers. Email, file transfer, online gaming, and voice communication may use the Internet without being part of the Web.

This distinction can be expressed as follows:

• Internet: the network of networks and its communication infrastructure.
• Web: a hyperlinked information and application system built on that infrastructure.

A web page is usually identified by a URL, requested using HTTP or HTTPS, delivered by a server, and interpreted by a browser. The Web is therefore an example of an application layer system that depends on lower-level networking technologies.

A Layered View of Web Communication

Web communication is easier to understand when considered in layers. The exact organisation varies between models, but a practical view is:

1. Physical and link layers move signals across cables, fibre, radio, or local networks.
2. Internet-layer protocols, especially IP, provide addressing and routing between networks.
3. Transport protocols, such as TCP or QUIC, support communication between endpoints. TCP provides reliable ordered delivery; QUIC provides transport functions over UDP and is used by HTTP/3.
4. Application protocols, such as HTTP, define how web clients and servers exchange messages.
5. Web content technologies, such as HTML, CSS, JavaScript, images, and video, define what is delivered and how it behaves.

These layers reduce complexity. A web developer generally does not manipulate electrical signals or manually route every packet. Instead, the developer works with application-level interfaces while understanding that lower layers affect reliability, latency, security, and performance.

Client–Server Architecture

A client is a program or device that requests a service. A server is a program or device that provides a service. In web development, the browser is usually the client and a web server is the server.

The architecture is not defined simply by the physical machine. One computer can run both client and server software, and a modern application may contain several server-side services. The important distinction is the role performed in a particular interaction.

A typical interaction follows this sequence:

1. A user enters a URL or selects a link.
2. The browser identifies the destination host.
3. DNS may translate the host name into an IP address.
4. The browser establishes a network connection.
5. It sends an HTTP request.
6. The server processes the request and returns an HTTP response.
7. The browser interprets the response and requests additional resources.
8. The browser constructs and displays the page.

Figure: Simplified relationship among a browser, DNS, and a web server.

Advantages and limitations

Client–server architecture centralises data and business rules where appropriate, permits many clients to use the same service, and simplifies updates to server-side software. However, it can introduce network latency, server bottlenecks, dependency on connectivity, and security risks. A well-designed application distributes suitable work between browser and server while protecting sensitive operations on trusted server-side systems.

Browsers and Web Servers

A web browser is client software that retrieves, interprets, and presents web resources. Major browser components include:

• a networking subsystem for DNS, connections, caching, and HTTP;
• an HTML parser and document model, commonly represented as the DOM;
• a CSS engine that calculates styles and layout;
• a JavaScript engine;
• graphics, media, storage, and security subsystems; and
• user-interface controls such as tabs, history, and developer tools.

The browser does not merely display an image supplied by a server. It parses HTML into a document tree, applies CSS, executes permitted JavaScript, fetches referenced resources, calculates layout, paints pixels, and responds to user events.

A web server is software that listens for requests and sends responses. Examples of server software include Apache HTTP Server, Nginx, Microsoft IIS, and application servers built with platforms such as Node.js, Java, Python, PHP, or .NET. The term “server” may refer to the software, the physical or virtual machine, or the overall service, so context matters.

A server may:

• return a file from a document directory;
• route a request to application code;
• query a database;
• authenticate a user;
• call another service;
• generate HTML or JSON; and
• record logs and enforce access controls.

URLs and URIs

A URI identifies a resource. A URL is a URI that provides a means of locating or accessing that resource. In everyday web development, “URL” is the usual term for a web address.

Consider:

https://shop.example.org:443/products/view?id=27#reviews

Its components are:

The fragment is normally processed by the browser and is not sent to the server as part of the HTTP request. Query strings, by contrast, are sent to the server and should not contain passwords or other secrets unless the design explicitly protects them; HTTPS encrypts them in transit but URLs may still be stored in histories, logs, or analytics systems.

URLs should be encoded correctly. For example, spaces are not normally transmitted as literal spaces in a URL; they are percent-encoded or represented according to the relevant component’s rules. Developers should use standard URL libraries rather than constructing complex URLs through unsafe string concatenation.

Domain Name System

People prefer memorable names such as www.example.org, while network communication uses IP addresses. The Domain Name System (DNS) is a distributed naming system that maps domain names to records, including address records.

A simplified lookup may involve:

1. the browser or operating system checking its cache;
2. a recursive resolver receiving the query;
3. the resolver contacting authoritative DNS infrastructure if necessary; and
4. the resolver returning an address record, which may then be cached for its time to live.

DNS is hierarchical. A name is read through labels separated by dots. In www.example.org, org is a top-level domain, example is a registered domain label, and www is a host or service label chosen by the domain owner.

DNS can return more than one address for availability or load distribution. It can also support records for mail delivery, aliases, text-based verification, and other services. DNS is not itself a substitute for authentication: resolving a name to an address does not prove that the response came from a trustworthy organisation. DNS Security Extensions (DNSSEC) can provide authenticity for DNS data, but application security still requires HTTPS and proper certificate validation.

Caching improves performance but means changes may not appear immediately. The time to live (TTL) indicates how long a response may be cached, subject to resolver behaviour and operational policy.

HTTP and HTTPS

HTTP, the Hypertext Transfer Protocol, is an application protocol for transferring web resources. It follows a request–response model. HTTP is designed to be stateless at the protocol level: each request can be understood independently, although cookies, tokens, and application mechanisms can create a user session.

A request commonly contains:

• a method, such as GET, POST, PUT, PATCH, or DELETE;
• a target path and query string;
• headers containing metadata; and
• an optional message body.

A response contains:

• a status code;
• response headers; and
• an optional body.

Common methods include:

“Safe” means that the method is intended not to change server state as a requested operation. “Idempotent” means that repeating the same request has the same intended effect as making it once; it does not mean the response body must be identical.

Status codes are grouped as follows:

• 1xx: informational;
• 2xx: successful processing, such as 200 OK or 201 Created;
• 3xx: redirection or use of cached information;
• 4xx: client-side request or authorization problems, such as 400, 401, 403, or 404; and
• 5xx: server-side failure, such as 500 or 503.

A 401 response generally indicates that authentication is required or has failed, whereas 403 indicates that the server understood the request but refuses to authorize it. A 404 indicates that a resource was not found, although applications sometimes deliberately conceal whether a protected resource exists.

HTTPS and transport security

HTTPS is HTTP carried through a secure transport, normally TLS. TLS provides encryption against casual interception, integrity protection against undetected modification, and authentication of the server through certificates issued within a trust system.

When a browser connects to an HTTPS site, it verifies the certificate’s validity, the domain identity, validity period, and trust chain according to browser policy. HTTPS does not automatically make an application safe. It cannot prevent insecure passwords, authorization errors, injection attacks, malicious scripts, poor access controls, or data leaks caused by the application itself.

Good practice includes using HTTPS for the whole site, redirecting HTTP carefully, enabling secure cookie attributes, avoiding mixed content, updating TLS configurations, and never treating the padlock indicator as proof that an organisation is honest.

Request–Response Processing in Practice

Suppose a user requests https://learn.example.edu/courses.

1. Input and parsing: The browser parses the URL and identifies the HTTPS scheme and host.
2. DNS resolution: The host name is resolved to one or more IP addresses.
3. Connection establishment: The browser establishes a secure transport connection. Depending on the protocol, this may involve TCP plus TLS or QUIC with TLS integration.
4. Request creation: The browser sends an HTTP request, including headers such as the host, accepted formats, and relevant cookies.
5. Routing: A reverse proxy, load balancer, or web server receives the request and selects an application route.
6. Application processing: The application validates input, checks permissions, reads or updates data if necessary, and prepares a response.
7. Response transmission: The server returns a status code, headers, and content such as HTML.
8. Resource discovery: The browser parses HTML and discovers CSS files, JavaScript files, fonts, images, and other resources.
9. Rendering: The browser builds a DOM and style information, performs layout, paints the page, and runs appropriate scripts.
10. Subsequent interaction: User actions may cause further requests, often using JavaScript and APIs that return HTML, JSON, or other formats.

The sequence is conceptually linear but operationally concurrent. Browsers can fetch multiple resources, reuse connections, cache responses, and progressively render content. Consequently, a page’s visible completion may depend on server latency, resource size, parsing, scripting, layout, and rendering—not only on the time required to deliver the initial HTML.

Web Standards and Interoperability

Web standards are documented technical rules and recommendations intended to make the Web interoperable. Organisations and communities involved in standards include the World Wide Web Consortium (W3C), the WHATWG, the Internet Engineering Task Force (IETF), and Ecma International, among others.

Important standards-related areas include:

• HTML syntax and semantics;
• CSS syntax, layout, and media features;
• ECMAScript, the standard underlying JavaScript language implementations;
• HTTP and URI specifications;
• accessibility guidance, including WCAG; and
• security and privacy mechanisms.

Standards support predictable behaviour across browsers, reduce vendor lock-in, and improve maintainability. Semantic HTML is especially valuable because it communicates meaning to browsers, search systems, assistive technologies, and other tools. A heading should be marked as a heading, navigation as navigation, and a button as a button rather than imitated with arbitrary elements.

Standards do not guarantee identical rendering on every device. Browsers differ in implementation, default styles, supported features, screen dimensions, and operating-system integration. Developers should use feature detection, progressive enhancement, responsive design, validation tools, and testing across representative browsers rather than relying on assumptions about one environment.

Static and Dynamic Websites

A static website delivers files whose contents are prepared before the request. A static page may contain HTML, CSS, JavaScript, images, and downloadable files. The server generally returns the requested file without generating personalised content for each request.

Static does not mean unchanging. Content can be updated by a build process, content management system, deployment pipeline, or administrator. It means that request-time generation is limited or absent.

A dynamic website creates or assembles content during or near request time. It may use application logic, databases, user identity, inventory data, permissions, or external services. A course portal, online banking system, and shopping cart are typical dynamic applications.

Modern systems often combine both models. A dynamic application may pre-render pages, cache generated responses, and serve static assets through a content delivery network. Conversely, a static site may use JavaScript to call dynamic APIs after the initial page loads.

Example of the distinction

A university department’s contact page can be a static HTML file if all visitors see the same information. A student timetable is dynamic because the server must identify the student, retrieve current enrolment data, apply access rules, and return an appropriate result. A static frontend may still display that timetable by requesting a protected API.

Professional Concerns: Performance, Security, Accessibility, and Privacy

Performance

Performance is influenced by DNS lookup time, connection setup, server processing, resource size, caching, JavaScript execution, and rendering. Useful practices include compressing suitable resources, using responsive images, reducing unnecessary scripts, setting cache policies, avoiding render-blocking resources where possible, and measuring real-user experience.

Caching must be designed carefully. Public resources can often use shared caches, while personalised responses require appropriate controls. Developers should understand cache invalidation, validation headers, and the risk of accidentally storing private data in shared caches.

Security

A foundational security model is to treat all client-provided data as untrusted. Validate input on the server, encode output according to its context, use parameterised database queries, enforce authentication and authorisation, protect sessions, apply least privilege, and log security-relevant events without exposing secrets.

Common web threats include cross-site scripting, cross-site request forgery, injection, broken access control, insecure direct object references, exposed credentials, and vulnerable dependencies. Security should be part of design and testing rather than an afterthought.

Accessibility

Accessible websites can be used by people with different visual, auditory, motor, cognitive, and technological circumstances. Professional practice includes semantic HTML, keyboard operability, meaningful labels, sufficient contrast, text alternatives for meaningful images, captions where needed, visible focus indicators, and clear error messages. Accessibility is both a quality responsibility and, in many jurisdictions, a legal or regulatory concern.

Privacy and governance

Web systems collect information through forms, accounts, cookies, analytics, logs, and third-party services. Organisations should collect only necessary data, explain purposes clearly, protect information, define retention periods, and respect applicable privacy and data-protection laws. Consent requirements vary by jurisdiction and processing purpose. Developers should avoid placing sensitive information in URLs, client-side storage, browser logs, or unprotected analytics events.

Applied Case: Illustrative Course Registration Portal

Background

A fictional college wants a portal through which students can view courses, register for available sections, and receive confirmation. The existing system consists of spreadsheets emailed to an administrator, causing delays and duplicate registrations.

Problem

The college needs a reliable web interface that supports many students, protects personal information, and reflects current seat availability. It must work on desktop and mobile browsers.

Analysis

The public course catalogue can be served as cached or pre-rendered content because it changes relatively infrequently. Registration is dynamic: it requires authentication, database access, transaction control, and authorisation. A student must not register another student, and two students must not be assigned the final seat simultaneously.

Approach and solution

The browser presents semantic HTML and responsive CSS. JavaScript improves filtering and submits registration requests through an API, but the server remains responsible for authentication, permission checks, validation, and final seat allocation. HTTPS protects data in transit. The server returns suitable status codes: a successful registration may return 201, an unauthorised request 401 or 403 depending on the condition, and a full course may return a documented application response.

The application uses a database transaction or equivalent concurrency control when reducing available seats. It records an audit event without storing unnecessary sensitive data. Static assets are cached, while personalised registration responses are given suitable cache directives. Accessible labels, keyboard support, and clear error messages are tested with representative users and tools.

Outcome

The catalogue loads quickly from cached content, while registration remains controlled by a secure dynamic service. The college gains consistent records, immediate confirmation, and a clearer operational audit trail.

Learning points

The case demonstrates that static and dynamic delivery are complementary rather than mutually exclusive. It also shows why a browser cannot be trusted with final business rules, why HTTPS is necessary but insufficient, and how standards, accessibility, performance, privacy, and security influence system design together.

Contemporary Developments

Web architecture continues to evolve. HTTP/2 supports multiplexed streams over a connection, while HTTP/3 uses QUIC and can improve behaviour on changing networks. Progressive web applications combine web technologies with capabilities such as offline caching and installation-like experiences, subject to browser support and security constraints. Content delivery networks distribute resources closer to users. Server-side rendering, static generation, and hybrid rendering seek to balance performance, search visibility, interactivity, and operational complexity.

WebAssembly can run compiled code in a browser under a security model, but it does not replace HTML, CSS, or JavaScript for general interface development. Artificial intelligence is increasingly used to generate, search, personalise, and moderate web content. Its use requires human review, protection of confidential data, attention to bias and accessibility, and verification of generated code. AI-generated software can contain security, licensing, correctness, or maintenance problems; professional responsibility remains with the development team.

Best-Practice Checklist

• Use HTTPS throughout the application.
• Prefer meaningful, stable URLs and encode them correctly.
• Use semantic HTML and standards-based CSS and JavaScript.
• Validate and authorise all sensitive operations on the server.
• Treat browser input, cookies, headers, and API data as untrusted.
• Separate public cacheable content from personalised responses.
• Test with keyboard navigation, assistive technologies, and multiple browsers.
• Measure performance rather than relying only on local development experience.
• Keep dependencies and server software updated.
• Minimise collection and exposure of personal data.
• Document APIs, status codes, error behaviour, and deployment assumptions.

Chapter Summary

The Internet is the global network infrastructure on which the World Wide Web operates. The Web uses browsers, servers, URLs, HTTP, HTML, and related standards to provide linked documents and interactive applications. In client–server architecture, a browser requests resources and a server processes requests and returns responses, although modern applications may contain multiple services and layers.

DNS maps human-readable domain names to network addresses. A URL identifies a resource through components such as scheme, host, port, path, query, and fragment. HTTP uses methods, headers, status codes, and optional bodies in a request–response model. HTTPS adds TLS-based confidentiality, integrity, and server authentication, but application security still depends on sound design.

Browsers parse and render resources, execute scripts, and interact with servers repeatedly. Web standards improve interoperability, semantics, accessibility, and maintainability. Static websites primarily deliver prebuilt resources, whereas dynamic websites generate or assemble content using application logic and data; many practical systems combine both. Professional web development must also address performance, accessibility, privacy, security, and responsible use of emerging technologies.

Key Terms

Internet: A global interconnection of networks and communication systems.

World Wide Web: A hyperlinked information and application system operating over the Internet.

Client: A program or device that requests a service.

Server: A program or system that provides a service to clients.

Browser: Client software that retrieves, interprets, and renders web resources.

Web server: Software that receives web requests and returns responses.

URL: A web-oriented URI that identifies and provides access to a resource.

URI: A uniform resource identifier.

DNS: The distributed naming system that maps domain names to records such as IP addresses.

IP address: A numerical network address used to identify an interface or endpoint.

HTTP: The application protocol used for web requests and responses.

HTTPS: HTTP protected by TLS-based secure transport.

TLS: A protocol providing transport encryption, integrity, and authenticated connections.

Request: A message sent by a client to ask a server to perform an operation.

Response: A server message containing status, metadata, and possibly content.

Status code: A three-digit HTTP result classification.

Static website: A site that primarily delivers prebuilt resources.

Dynamic website: A site that generates or assembles content using request-time logic or data.

Web standard: A documented technical rule or recommendation supporting interoperable implementation.

DOM: The browser’s structured representation of an HTML document.

Review Questions

Short Answer Questions

1. What is the difference between the Internet and the World Wide Web?
2. Identify the main components of a URL and state the purpose of each.
3. What role does DNS play in accessing a website?
4. Distinguish HTTP from HTTPS.
5. What is the principal difference between a static and a dynamic website?

Long Answer Questions

1. Explain the complete sequence of events that occurs when a user enters an HTTPS URL into a browser.
2. Describe client–server architecture and discuss two advantages and two limitations.
3. Explain HTTP methods, headers, bodies, and status-code classes in the request–response model.
4. Discuss how web standards contribute to interoperability, accessibility, and maintainability.
5. Compare static and dynamic websites, including their architecture, performance, security, and typical uses.

Analytical / Application Questions

1. A college website serves a public course catalogue and a private student timetable. Recommend which parts should be static or dynamic and justify your decision.
2. A developer places a student’s identification number in a URL query string. Analyse the privacy and security risks and propose a safer design.
3. A page loads quickly on the developer’s laptop but slowly on mobile networks. Identify at least five possible causes and propose a structured investigation.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes the Internet from the World Wide Web?

A. The Internet is a global network infrastructure, while the Web is an application system operating on it.

B. The Internet is a type of browser, while the Web is a type of server.

C. The Internet only carries email, while the Web only carries video.

D. The Internet and the Web are exactly the same system.

Correct Answer: A. The Internet is a global network infrastructure, while the Web is an application system operating on it.

Question 2

In a typical web interaction, which component usually acts as the client?

A. A DNS root server

B. A web browser

C. A database table

D. A TLS certificate

Correct Answer: B. A web browser

Question 3

In the URL https://example.org/products?id=27#reviews, what does reviews represent?

A. The scheme

B. The host

C. The fragment

D. The port

Correct Answer: C. The fragment

Question 4

What is the primary function of DNS?

A. To style HTML documents

B. To encrypt database records

C. To map domain names to network-related records

D. To generate JavaScript code

Correct Answer: C. To map domain names to network-related records

Question 5

Which HTTP status-code class generally indicates a successful request?

A. 1xx

B. 2xx

C. 4xx

D. 5xx

Correct Answer: B. 2xx

Question 6

What additional protection does HTTPS provide compared with ordinary HTTP?

A. Guaranteed correct application logic

B. Transport encryption, integrity protection, and server authentication through TLS

C. Automatic protection from all browser vulnerabilities

D. Permanent storage of every web page

Correct Answer: B. Transport encryption, integrity protection, and server authentication through TLS

Question 7

Which statement about a URL fragment is generally correct?

A. It identifies a location within the returned resource and is normally processed by the browser.

B. It always identifies the server’s IP address.

C. It replaces the domain name during DNS resolution.

D. It is the same as the HTTP method.

Correct Answer: A. It identifies a location within the returned resource and is normally processed by the browser.

Question 8

Which example is most clearly dynamic?

A. A fixed copyright notice in an HTML file

B. A logo image served from a public directory

C. A student timetable generated after checking the student’s account and database records

D. A prebuilt CSS stylesheet

Correct Answer: C. A student timetable generated after checking the student’s account and database records

Question 9

Why is semantic HTML professionally valuable?

A. It guarantees that every browser displays identical pixels.

B. It communicates document meaning to browsers, assistive technologies, and other tools.

C. It eliminates the need for CSS.

D. It prevents all network failures.

Correct Answer: B. It communicates document meaning to browsers, assistive technologies, and other tools.

Question 10

Which operation should remain under server-side control in a course registration system?

A. Changing the browser window colour

B. Selecting a visual font size

C. Final authorisation and allocation of a limited course seat

D. Displaying a navigation icon

Correct Answer: C. Final authorisation and allocation of a limited course seat