How the Web Works: Client, Server, HTTP Request and Response

When you type a website address into your browser and press Enter, a chain of network interactions executes in a fraction of a second. To write backend code in PHP with confidence, it is essential to understand what happens between a user's keystroke and the rendering of a finished web page: how the browser discovers the server, how an HTTP request is constructed, how the web server delegates execution to PHP, and how the response travels back.

The Client-Server Architecture

The modern web is built upon the client-server model. Two primary parties participate in every interaction:

1. Client: The program requesting resources or data. In most situations, this is a web browser (Google Chrome, Firefox, Safari), a mobile app, or a command-line tool like curl.
2. Server: A computer or cluster connected to the network, running continuously, listening for incoming connections, and serving requested files, HTML pages, or JSON APIs.

+-------------------+           HTTP Request                   +-----------------------+
|      CLIENT       | ---------------------------------------> |      WEB SERVER       |
| (Browser, Chrome) | <--------------------------------------- | (Nginx, Apache, PHP)  |
+-------------------+           HTTP Response                  +-----------------------+

The client is always the initiator of communication. The server passively waits for requests, processes them according to HTTP specifications, and sends back a response.

The Journey from URL to Rendered Page

Let us trace step-by-step what occurs when navigating to https://kurslar.prowid.com/courses:

💡 You can inspect DNS records in your terminal using nslookup or dig: for example, nslookup kurslar.prowid.com.

Anatomy of HTTP Requests and Responses

The HTTP (HyperText Transfer Protocol) is an application-level, text-based protocol operating on a request-response cycle.

Structure of an HTTP Request

An HTTP request consists of three distinct parts:

1. Request Line: Specifies the HTTP method (GET, POST, PUT, DELETE), the requested URI path (/courses?cat=backend), and the protocol version (HTTP/1.1).
2. Headers: Key-value pairs transmitting client metadata, acceptable media formats, authentication cookies, and encoding specifications.
3. Body: Payload sent when submitting forms or JSON payloads (commonly in POST, PUT, PATCH requests); GET requests do not carry a body.

Example raw HTTP request:

GET /courses?lang=en HTTP/1.1
Host: kurslar.prowid.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Cookie: session_id=abc123xyz789
Connection: keep-alive

Structure of an HTTP Response

The server response follows a mirrored layout:

1. Status Line: Protocol version, three-digit status code, and reason phrase (e.g., HTTP/1.1 200 OK or 404 Not Found).
2. Response Headers: Metadata such as MIME type (Content-Type), length (Content-Length), cookie directives (Set-Cookie), date, and server software.
3. Response Body: The actual content delivered—HTML layout, JSON data, an image, or a file stream.

Example raw HTTP response:

HTTP/1.1 200 OK
Date: Wed, 30 Sep 2026 07:00:00 GMT
Server: Apache/2.4.58
Content-Type: text/html; charset=UTF-8
Content-Length: 180
Set-Cookie: visited=1; Path=/; HttpOnly

<!DOCTYPE html>
<html lang="en">
<head><title>PHP Courses</title></head>
<body>
  <h1>Welcome to the PHP Course!</h1>
</body>
</html>

Common HTTP Status Code Categories

Static vs. Dynamic Content: Where PHP Fits In

Web resources are categorized into static assets and dynamic scripts:

• Static Assets (.html, .css, .js, .png, .svg): Exist in finalized form on the server storage. The web server (such as Nginx) simply reads the bytes from disk and pushes them over the network connection without alteration.
• Dynamic Pages (.php): A pre-rendered HTML file may not exist on disk at all. Instead, the web server executes the PHP interpreter, forwards request parameters (query strings, form submissions, cookies), and PHP runs business logic (fetching data from MySQL, validating credentials, rendering templates) to generate HTML in real time.

[Browser]
   │
   │ 1. HTTP Request (GET /profile.php)
   ▼
[Web Server: Nginx / Apache]
   │
   │ 2. Identifies .php file -> Passes to PHP
   ▼
[PHP Interpreter]
   │
   │ 3. Executes code, queries MySQL, builds HTML
   ▼
[Generated HTML Content]
   │
   │ 4. HTTP Response with Content-Type: text/html
   ▼
[Browser Renders Page]

To the browser, there is no difference between a static file and the output generated by PHP—both arrive as standard HTTP responses with markup.

Hands-On: Inspecting Requests with cURL and DevTools

You can observe HTTP communication firsthand using two straightforward tools.

Method 1: The cURL Command-Line Tool

The -i flag instructs curl to display response headers alongside the payload body, while -v (verbose) illustrates the full socket handshake and request transmission:

curl -i https://httpbin.org/get

HTTP/1.1 200 OK
Date: Wed, 30 Sep 2026 07:15:00 GMT
Content-Type: application/json
Content-Length: 255
Connection: keep-alive
Server: gunicorn/19.9.0
Access-Control-Allow-Origin: *

{
  "args": {}, 
  "headers": {
    "Accept": "*/*", 
    "Host": "httpbin.org", 
    "User-Agent": "curl/8.4.0"
  }, 
  "origin": "94.20.18.12", 
  "url": "https://httpbin.org/get"
}

Method 2: Browser Network DevTools

1. Open any website in your browser.
2. Press F12 (or Ctrl+Shift+I / Cmd+Opt+I) and navigate to the Network tab.
3. Refresh the page (F5 or Ctrl+R).
4. You will see every asset requested: HTML document, stylesheets, JavaScript files, and images. Clicking on the initial document entry reveals Headers (request and response headers), Payload (submitted parameters), and Response (rendered markup).

⚠️ Important Note: PHP executes solely on the server (Server-Side). The end-user in the browser never sees raw PHP source code, only the final rendered output.