Web Programming Fundamentals
Every PHP app lives inside the HTTP request-and-response cycle. A request comes in, your code runs, a response goes out, and PHP forgets everything. Once that really sinks in, routing, forms, logins, APIs, caching, and debugging all make a lot more sense.
On this page
The request cycle
- The browser resolves the host. DNS returns the address of the web server or reverse proxy.
- A connection is established. HTTPS adds TLS negotiation before HTTP data is exchanged.
- The browser sends a request. The request includes a method, path, headers, and sometimes a body.
- The web server invokes PHP. Apache, nginx with PHP-FPM, or another server passes the request to the application.
- The application runs. It validates input, loads data, applies business rules, and produces a response.
- The browser receives the response. It uses the status code, headers, and body to decide what to display or do next.
GET /customers/42 HTTP/1.1 Host: example.test Accept: text/html Cookie: session_id=abc123
HTTP methods mean something
| Method | Typical purpose | Expected behavior |
|---|---|---|
GET | Read a page or resource | Should not create, modify, or delete data. |
POST | Create or submit an action | Usually has a request body and may change state. |
PUT | Replace a resource | Common in APIs and generally idempotent. |
PATCH | Partially update a resource | Changes only specified fields. |
DELETE | Remove a resource | Should require authorization and CSRF protection in browser applications. |
Status codes are part of the interface
| Code | Use |
|---|---|
200 OK | A normal successful response. |
201 Created | A resource was created successfully. |
204 No Content | The action succeeded and no body is needed. |
302 Found / 303 See Other | Redirect after an action, often following a successful form POST. |
400 Bad Request | The request is malformed. |
401 Unauthorized | Authentication is required or invalid. |
403 Forbidden | The identity is known but lacks permission. |
404 Not Found | The requested resource does not exist or should not be revealed. |
422 Unprocessable Content | The request is structurally valid but fails validation. |
500 Internal Server Error | An unexpected application failure occurred. |
Headers, content types, and cookies
Headers are the metadata riding along with every request and response. The ones I end up dealing with most are Accept, Content-Type, authorization headers, caching headers, and the forwarding headers a reverse proxy adds. (Those last ones have their own page.)
<?php
declare(strict_types=1);
header('Content-Type: application/json; charset=utf-8');
header('Cache-Control: no-store');
http_response_code(200);
echo json_encode(
['status' => 'ok'],
JSON_THROW_ON_ERROR
);
HTTP doesn't remember you
Every request stands on its own. Sessions fake continuity by keeping data on the server and tying it to an ID in a cookie. And since the browser controls everything it sends, never base authentication on a hidden form field or a query string value. Anyone can change those.
Know what you can trust (not much)
- Everything from
$_GET,$_POST, cookies, JSON bodies, and uploaded files is untrusted. - Headers can be forged unless a trusted reverse proxy replaces or validates them.
- Database values may still require escaping when rendered into HTML.
- Authorization must be checked on every protected action, not only when the menu is displayed.
- Validation answers “is this input acceptable?” while escaping answers “is this output safe in this context?”