HTTP and Web Basics
HTTP connects clients and servers through requests and responses. A browser loading a page may make many requests for HTML, scripts, styles, images and data.
Following a request
A URL identifies a scheme, host and resource, with an optional port and query. DNS helps resolve the host. HTTPS uses TLS to protect traffic and authenticate the server under the browser's trust rules.
The HTTP request carries a method, target, headers and sometimes a body. The response carries a status, headers and sometimes a body. The body format is described by its content type.
See MDN's HTTP overview.
Methods and status
| Item | Meaning |
|---|---|
| GET | Retrieve a representation |
| POST | Submit data for processing |
| PUT | Create or replace the target's state under its contract |
| DELETE | Request removal of the target's association |
| 2xx | Successful response |
| 3xx | Redirection or related response |
| 4xx | Client-side problem under the server's rules |
| 5xx | Server-side failure |
An idempotent method has the same intended effect when repeated as when performed once. It need not return identical responses. A timeout can leave the client uncertain whether a request took effect. See HTTP semantics.
Cookies and authentication
A cookie carries state between requests within its scope. A session identifier is useful only when the server validates it and protects the session. Authentication identifies a caller; authorisation decides what that caller may do.
CORS governs certain browser access to cross-origin responses. It does not replace authentication or stop non-browser clients from sending requests.
Caching
A cache can reuse a response when its freshness and cache rules allow it. Validators such as ETags support checking whether a stored response remains current. Make cache rules deliberate for personalised data.
Debugging the path
Use the browser's network panel to inspect the actual URL, request, status, headers and body. Check whether the failure is DNS, connection, TLS, HTTP or application-level. A successful HTTP status can still contain data your application cannot use.
See Hosting on the SRCF for deployment and Debugging for narrowing a failure.