How the web works (basic overview)

The Big Picture: How the Web Works

When you build web apps with Python, you are really joining a big conversation between browsers and servers. To understand what your Python code is doing, you need a mental model of that conversation.

This section gives you a beginner-friendly overview of:

• What happens when you visit a website
• The roles of browser, server, and internet
• URLs, HTTP, and requests/responses
• Static vs dynamic content
• Where Python fits into all this

The Journey of a Web Page Request

When you type something like:

https://example.com/about

into your browser and press Enter, a lot of things happen very quickly. Simplified, the flow looks like this:

1. You (the user) type a web address into the browser.
2. The browser figures out which server to contact.
3. A request is sent over the internet to that server.
4. The server (often running Python) receives the request.
5. The server decides what content to send back (HTML, images, etc.).
6. A response is sent back to your browser.
7. The browser displays the page for you.

You can think of it like sending a letter (the request) to a company (the server) and getting a reply (the response) with the information you asked for.

The Main Players: Browser, Server, Internet

Browser (Client)

• Examples: Chrome, Firefox, Safari, Edge.
• It’s called a client because it asks for information.
• It:
• Takes a URL you give it.
• Sends a request to the correct server.
• Receives the response.
• Renders (draws) the page using HTML, CSS, and JavaScript.

When you build a Python web app, your code usually runs on the server, not in the browser.

Server

• A server is a computer that:
• Is connected to the internet.
• Listens for incoming web requests.
• Sends back responses.
• It often runs:
• A web server program (like Nginx, Apache, or a simple development server).
• Your Python web application (for example, written with Flask).

The browser never runs your Python code directly. Instead, the server runs Python, generates content (usually HTML), and sends that content to the browser.

The Internet (The Network in Between)

You can think of the internet as a huge postal system and road network:

• It moves data (like letters) between clients and servers.
• Uses lots of smaller networks connected together.
• Uses standard rules (called protocols) so everything can communicate.

URLs: Web Addresses

A web address like:

https://example.com:443/about?lang=en#team

is called a URL (Uniform Resource Locator). It has parts:

• https – The protocol (the set of rules) for communication. Common ones:
• http – HyperText Transfer Protocol
• https – HTTP with encryption (secure)
• example.com – The domain name (human-friendly name for a server).
• :443 – The port (optional, usually hidden). A number telling the server which program should handle the request. Common ports:
• 80 – HTTP default
• 443 – HTTPS default
• /about – The path – which resource you’re asking for on that server.
• ?lang=en – The query string – extra data you send with the URL.
• #team – The fragment – tells the browser which part of the page to jump to (not sent to the server).

For web development, you will often focus on:

• The path (/about)
• The query string (?lang=en)

In Python frameworks, you’ll map paths (like /about) to functions in your code.

HTTP: The Language of the Web

HTTP (HyperText Transfer Protocol) is the main protocol used for web communication. It defines how clients and servers talk.

Requests and Responses

The web is based on a simple pattern:

• The client sends a request.
• The server sends back a response.

A Simple HTTP Request (conceptual)

When you visit https://example.com/about, your browser might send a request like:

GET /about HTTP/1.1
Host: example.com
User-Agent: MyBrowser
Accept: text/html

Important parts:

• GET – The HTTP method (what kind of action you want).
• /about – The path on the server.
• Host: example.com – Which domain.
• Other lines are headers: extra information about the request.

A Simple HTTP Response (conceptual)

The server might answer with:

HTTP/1.1 200 OK
Content-Type: text/html
<html>
  <body>
    <h1>About This Site</h1>
  </body>
</html>

Important parts:

• 200 OK – The status code (request succeeded).
• Content-Type: text/html – The type of data being returned.
• Then the body: the actual content (here, HTML).

Common HTTP Methods (High Level)

You’ll see these methods a lot:

• GET – Ask for data (like a page or image).
• POST – Send data (like form data) to the server to create or process something.
• PUT / PATCH – Send data to update something.
• DELETE – Request deletion of something.

In your Python web apps, you will write code that behaves differently based on the method (for example, GET vs POST).

HTTP Status Codes (High Level)

Servers respond with status codes to indicate what happened:

• 200 – OK (success)
• 301, 302 – Redirect (the resource moved)
• 400 – Bad request (client sent something invalid)
• 401 – Unauthorized (needs login)
• 403 – Forbidden (not allowed)
• 404 – Not found (no such page)
• 500 – Internal server error (something broke on the server)

As a Python web developer, you’ll often:

• Return 200 when all is good.
• Handle or display 404 when something is missing.
• See 500 when your Python code has a bug.

Static vs Dynamic Content

Not all pages are created the same way.

Static Content

• The file already exists on the server.
• Examples: simple HTML files, images, CSS files.
• The server mostly reads a file and sends it.

For example, a static HTML file:

about.html

When requested, the server just sends it as-is.

Dynamic Content

• The page is generated on the fly when the request arrives.
• Often created by code running on the server (for example, Python).
• Content can change depending on:
• The user (logged in vs guest)
• Data from a database
• Time, location, or other inputs

For example, a Python function might:

1. Read from a database.
2. Insert that information into an HTML template.
3. Return the final HTML to the browser.

Most modern web apps use a lot of dynamic content.

Where Python Fits In

When you write web apps with Python:

• Your Python code runs on the server, not in the browser.
• A Python web framework (like Flask) helps:
• Listen for HTTP requests.
• Match URLs/paths (like /about) to Python functions.
• Create responses (HTML, JSON, etc.) to send back.

Conceptually:

1. Browser sends a request: GET /hello.
2. The server (with Python) receives it.
3. Python code runs something like:

   def hello():
       return "<h1>Hello, world!</h1>"

4. The server sends that HTML back to the browser.
5. The browser shows "Hello, world!" to the user.

You’ll soon see how frameworks like Flask make this routing from URL → Python function easy to set up.

Client-Side vs Server-Side

Two main “sides” work together in a web app:

Server-Side (Where Python Lives)

• Code runs on the server.
• Written in languages like Python, JavaScript (Node.js), Ruby, etc.
• Handles:
• Business logic (rules of your app)
• Accessing and modifying data (databases)
• Security-sensitive operations (password checking, etc.)
• Generating responses (HTML or data)

Client-Side (In the Browser)

• Code runs in the user’s browser.
• Typically HTML, CSS, and JavaScript.
• Handles:
• Layout and styling.
• Interactivity in the page (buttons, animations).
• Some input validation before sending data to the server.

Your Python code focuses on the server-side. The browser never sees your Python source code; it only sees the final HTML, CSS, JavaScript, images, etc.

Stateful Users on a Stateless Protocol

HTTP itself is stateless:

• Each request is independent.
• The server does not automatically “remember” previous requests.

But web apps feel like they have memory: you can log in, stay logged in, keep items in a shopping cart, etc. This is done using things like:

• Cookies – Small pieces of data saved in the browser and sent with requests.
• Sessions – Server-side storage that tracks data per user, often linked to a cookie.

The important idea for now: your Python code helps “add state” on top of a stateless protocol so your app can remember users and their data across multiple requests.

Putting It All Together (Conceptual Flow)

Here’s a simple flow for a Python-based web app:

1. You enter a URL in the browser: https://myapp.com/profile.
2. Browser sends an HTTP GET request for /profile.
3. The server receives /profile and passes it to your Python app.
4. Your Python function:
• Checks who is logged in.
• Fetches their data from a database.
• Inserts that data into an HTML template.
5. Python returns the final HTML to the server.
6. The server sends an HTTP response with status 200 and Content-Type: text/html.
7. The browser displays the personalized profile page.

In the next sections of this chapter’s parent topic, you’ll start using a specific tool (Flask) to implement this flow in real code.