Codectionary / Developer documentation / PHP

Follow a PHP web request from the browser through a web server and PHP runtime to the response, with clear explanations of PHP-FPM, sessions and output formats.

The browser and the server have different jobs

A browser runs on the visitor’s device. It sends requests, receives responses, renders HTML and CSS, and can run browser JavaScript. A server receives requests and can run PHP code before replying. PHP source is normally processed on the server; the browser sees the resulting response, not the instructions that produced it.

An HTTP request contains a method such as GET or POST, a URL, headers and sometimes a body. The response contains a status code, headers and usually a body. A Content-Type header tells the browser whether that body is HTML, JSON or something else. After receiving HTML, the browser may request separate CSS, JavaScript and image files.

A request from start to finish

Imagine visiting /courses.php. The following path describes a common server-rendered request. Routing and execution details vary with the host, web server and application framework; a cache may also satisfy some requests without running PHP.

  1. A visitor opens a website in a browser.
  2. The browser sends an HTTP request for a URL, such as GET /courses.php.
  3. A web server receives the request and decides how that URL should be handled.
  4. If PHP processing is configured for that request, the server passes it to the PHP execution environment. Some applications route many URLs through one entry-point script.
  5. PHP runs the relevant application code and reads request data if needed. Submitted data must be checked before use.
  6. The code may ask a database or another service for information. A database is optional, not an automatic part of PHP.
  7. PHP produces response content and can set a status code and headers. The web server sends the resulting HTTP response.
  8. The browser receives the response. It renders HTML, or gives JSON to the browser code that requested it.

Where Apache, Nginx and PHP-FPM fit

Apache and Nginx are web servers: they receive HTTP requests and can serve static files. They can also be configured to hand appropriate requests to PHP. PHP-FPM (FastCGI Process Manager) is one common way to manage PHP worker processes that execute those requests. In a typical Nginx setup, Nginx passes PHP requests to FPM; Apache can also use FPM, though other Apache/PHP arrangements exist.

The PHP execution engine reads the source, parses and compiles it into internal instructions, then executes those instructions. An opcode cache may reuse compiled instructions on later requests. Beginners often call this “interpreting PHP,” but the exact compilation, caching and worker behaviour depends on the implementation and configuration.

FPM is not the PHP language and does not replace the web server. The PHP command-line interface is another execution environment: php script.php runs a file from a terminal, without an HTTP request. Avoid assuming that CLI and web execution load the same configuration or extensions.

Why the browser does not normally see PHP source

The server should execute a requested PHP entry point and send only its output. For example, echo can add text to an HTML response. The response may be HTML, JSON, plain text or another content type; PHP is not restricted to generating webpages.

Correct hosting configuration matters. A server that serves a PHP file as plain text instead of passing it to PHP, or exposes configuration and secret files inside its public directory, can leak source code or credentials. Keep secrets out of public files, restrict access to PHP-FPM and check deployment configuration rather than assuming a .php extension is protective.

Cookies and sessions across requests

HTTP requests are separate events. A cookie is a small value a server can ask the browser to store and send with later matching requests. A PHP session commonly uses a cookie containing a session identifier to find data retained by a server-side session handler. The storage mechanism and cookie settings depend on the application and host.

The session identifier is not the same as the user’s whole account record. A session can help a site recognise a signed-in visitor, but it must be configured and protected appropriately. Do not trust a cookie simply because the browser sent it; clients can alter values they control.

Return a page or return data

The first example below returns an HTML page. PHP reads a query parameter, checks that it is a string and escapes it before placing it into HTML. Visit /index.php?name=Sam through a PHP-capable local server to see “Hello, Sam!”. Opening the file directly in a browser will not execute PHP.

The second example returns JSON. Its Content-Type header must be sent before output. A browser or mobile app can request the URL and parse its JSON; it will not render the data as a webpage by itself. The PHP built-in server can serve these examples for local learning, but the PHP manual warns against using it as a public production server.

Local development, from the folder containing index.php

php -S 127.0.0.1:8000

What to learn next

Practice identifying which data arrives in the request and which bytes leave in the response. Then learn how PHP validates inputs, maintains sessions and talks to databases. The same boundary matters for both full webpages and JSON APIs.

Syntax

<?php
header("Content-Type: application/json; charset=utf-8");
echo json_encode(["message" => "Hello"]);

Examples

Generate a small HTML response

Save as index.php and visit /index.php?name=Sam through a local PHP server.

<?php
$rawName = $_GET['name'] ?? 'visitor';
$name = is_string($rawName) ? $rawName : 'visitor';
$safeName = htmlspecialchars($name, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
?>
<!doctype html>
<html lang="en">
<head><meta charset="UTF-8"><title>Greeting</title></head>
<body><h1>Hello, <?= $safeName ?>!</h1></body>
</html>
  1. The browser sends the name in the URL. $_GET reads the query parameter; ?? supplies a default if it is absent.
  2. A query parameter can be an array, so is_string checks its type. htmlspecialchars makes the value safe for HTML text before the short echo tag inserts it.
  3. PHP runs on the server and returns ordinary HTML. With name=Sam, the rendered heading says Hello, Sam!; the browser does not receive the PHP statements.

Return JSON from a PHP endpoint

Save as api.php and request /api.php; the response body is JSON.

<?php
header('Content-Type: application/json; charset=utf-8');
echo json_encode(['course' => 'PHP basics', 'lessons' => 5], JSON_THROW_ON_ERROR);
  1. header sets the response media type before any body content is written, so a client can recognise JSON.
  2. json_encode converts a PHP associative array to JSON text. JSON_THROW_ON_ERROR reports encoding failure instead of silently returning false.
  3. The body is {"course":"PHP basics","lessons":5}. A browser may display that text; a JavaScript client can parse and use its fields.

Best practices

  • Treat every request value as untrusted and escape text for its output context.
  • Keep PHP source and secrets behind correctly configured server routing; never expose PHP-FPM to an untrusted network.
  • Use the built-in PHP server for local learning only, not public production hosting.

Runtime & versions

PHP runtime on a server or CLI. Feature availability depends on the language and runtime version used by your project; consult the official reference below.

PHP Manual

Specifications & further reading