HTTP and the Web Standards Model Review

## Servers and the Client-Server Model - **Server**: A computer or program that receives requests from other computers and sends data or services back over the network. The term refers to both the physical hardware and the software running on it. - **Client-Server Model**: A distributed architecture where clients send requests and servers handle those requests and return responses. - **Client**: The process or application (for example, a web browser) that initiates requests to a server. - **Request-Response Cycle**: The client sends a request; the server processes it and returns a response. ### Server Types - **Web servers**: Deliver web content (HTML, images, CSS) to browsers. - **Application servers**: Handle business logic and process user input. - **Database servers**: Store, retrieve, and manage data. - **Mail servers**: Send, receive, and store email. - **File servers**: Manage file storage and sharing across a network. - **Proxy servers**: Act as intermediaries between clients and other servers. ## DNS (Domain Name System) - **DNS**: A hierarchical and decentralized naming system that translates human-readable domain names into IP addresses, often called the "phone book" of the internet. - **IP Address**: A unique numerical identifier for a device on a network (for example, `127.0.0.1` in IPv4, `0:0:0:0:0:0:0:1` in IPv6). - **Domain Name Hierarchy** (read right to left): - **TLD (Top-Level Domain)**: The rightmost segment (for example, `.org`, `.com`). - **SLD (Second-Level Domain)**: The registered name (for example, `freecodecamp` in `freecodecamp.org`). - **Subdomain**: Identifies a section of the main domain (for example, `www`, `blog`, `api`). ### DNS Resolution Process 1. The browser sends the domain name to the **Recursive Resolver** (usually managed by the ISP). 2. The Recursive Resolver queries **Root Servers**, which direct it to the relevant TLD server. 3. The **TLD Server** returns the address of the **Authoritative Name Server** for the domain. 4. The Authoritative Name Server returns the **DNS Record** containing the IP address. 5. The Recursive Resolver delivers the IP address to the client and **caches** the record to speed up future lookups. ## TCP/IP - **Protocol**: A set of rules and standards that allow devices to communicate over a network. - **TCP/IP**: A suite of protocols that determines how data is packaged, sent, routed, and received. - **IP (Internet Protocol)**: Routes data packets from source to destination using IP addresses. It is connectionless — each packet travels independently with no delivery guarantee. - **TCP (Transmission Control Protocol)**: Breaks data into numbered segments, reassembles them at the destination, checks for errors and lost packets, and requests retransmission if needed. Ensures reliable, ordered delivery. ## HTTP (HyperText Transfer Protocol) - **HTTP**: An application-level protocol that defines the rules for communication between clients and servers on the web. - **HTTPS**: A secure version of HTTP where data is encrypted using SSL/TLS before transmission. ### HTTP Request Structure - **Request line**: `METHOD /path HTTP/version` (for example, `GET / HTTP/1.1`) - **Headers**: Key-value metadata pairs (for example, `Content-Type: application/json`). - **Body** (optional): Data sent to the server, used with `POST`, `PUT`, and `PATCH`. **Common HTTP methods:** | Method | Purpose | | --- | --- | | `GET` | Retrieve data | | `POST` | Submit new data | | `PUT` | Replace a resource | | `PATCH` | Partially update a resource | | `DELETE` | Remove a resource | ```md GET / HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html Connection: keep-alive ``` ### HTTP Response Structure - **Status line**: HTTP version, status code, and reason phrase (for example, `HTTP/1.1 200 OK`). - **Headers**: Metadata about the response (for example, `Content-Type: text/html`). - **Body** (optional): The returned content or error explanation. ```md HTTP/1.1 200 OK Content-Type: text/html Content-Length: 105 Connection: keep-alive <!DOCTYPE html> <html> <head><title>Home</title></head> <body><h1>Welcome!</h1></body> </html> ``` ## HTTP Status Codes Status codes are grouped by their first digit: - **1xx** — Informational responses. - **2xx** — Successful responses. - **3xx** — Redirection messages. - **4xx** — Client error responses. - **5xx** — Server error responses. ### Common Codes | Code | Name | Meaning | | --- | --- | --- | | `200` | OK | Request succeeded; content returned. | | `201` | Created | Resource created successfully. | | `204` | No Content | Success but no content to return. | | `301` | Moved Permanently | Resource permanently moved to a new URL. | | `302` | Found | Resource temporarily moved to another URL. | | `304` | Not Modified | Resource unchanged since last request; use cached version. | | `400` | Bad Request | Server couldn't understand the request (invalid syntax or data). | | `401` | Unauthorized | Authentication credentials required. | | `403` | Forbidden | Client lacks permission for the resource, even with valid credentials. | | `404` | Not Found | Resource doesn't exist on the server. | | `500` | Internal Server Error | Unexpected error on the server. | | `502` | Bad Gateway | Server received an invalid response from an upstream server. | | `503` | Service Unavailable | Server temporarily unable to handle requests. | ## The HTTP Request-Response Model The request-response cycle consists of these components working together: - **Client**: Browser, mobile app, or API client that sends HTTP requests. - **HTTP Method**: The action to perform (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`). - **URL**: The address of the resource being requested. - **Headers**: Metadata for the request or response (for example, `Authorization`, `Content-Type`). - **Body**: Data sent with `POST`, `PUT`, `PATCH`, or `DELETE` requests (often JSON or form data). - **Server**: The back-end system that processes requests and returns responses. - **Status Code**: Numeric code indicating success, error, or redirect. - **Response Body**: The actual data returned, typically HTML, JSON, or XML. ### The Six Steps of the Cycle 1. **Client initiates a request** with a method, URL, headers, and optional body. 2. **Request travels to the server** over the internet. 3. **Server processes the request**: checks method, URL, authentication, and queries a database if needed. 4. **Server prepares a response** with a status code, headers, and optional body. 5. **Response is sent back** to the client. 6. **Client handles the response**: renders data on success (2xx) or displays an error message on failure (4xx/5xx). ## HTTP Response Assets and Content-Types The `Content-Type` header tells the browser how to handle the asset in a response. | Asset | Content-Type | | --- | --- | | HTML | `text/html` | | CSS | `text/css` | | JavaScript | `application/javascript` | | JSON | `application/json` | | XML | `application/xml` | | JPEG | `image/jpeg` | | PNG | `image/png` | | GIF | `image/gif` | | SVG | `image/svg+xml` | | WebP | `image/webp` | | MP4 | `video/mp4` | | MP3 | `audio/mpeg` | | PDF | `application/pdf` | | ZIP | `application/zip` | | WOFF2 | `font/woff2` | ## HTML Form Submissions - Forms collect and submit user data using the `<form>` element with `<input>` elements. - Each input needs a `name` attribute so the server can identify the data. - **Client-side validation**: Use the `required` and `pattern` attributes for immediate feedback. - **Server-side validation**: Always validate on the server for security, regardless of client-side checks. - The `action` attribute specifies where to send the form data. - The `method` attribute specifies how to send it (`GET` or `POST`; `PUT`, `PATCH`, `DELETE` require workarounds such as the Fetch API or `method-override` in Express). ### Form Submission Flow 1. User fills out and submits the form. 2. Browser runs client-side validation; proceeds if valid. 3. Browser sends form data to the URL in `action` using the specified `method`. 4. Server receives and processes the data (store in database, authenticate user, etc.). 5. Server may run additional server-side validation. 6. Server responds with a success message, an error, or a redirect. 7. User sees feedback based on the server's response. ## Web Standard Model and Standards Bodies - **Web standards**: The rules and specifications that browsers follow to render pages and enable web capabilities. - **WHATWG**: The standards body that maintains HTML and the DOM as a continuously updated "living standard" driven by major browser engine teams. - **W3C**: The primary standards organization, overseeing CSS, SVG, accessibility guidelines (WCAG), and numerous web APIs. - **ECMA / TC39**: ECMA publishes the ECMAScript specification (the JavaScript standard); TC39 advances language features through a five-stage proposal process (Stage 0–4). - **Khronos Group**: Responsible for WebGL and WebGL 2, which bring GPU-accelerated 3D rendering to the browser. ## The Process for Creating Web Standards 1. **Identifying a need**: A developer or browser engineer documents a real, widely shared problem. 2. **Proposal and early discussion**: The idea is written up informally to gather feedback and gauge browser vendor interest. 3. **Writing the specification**: A precise, formal document is drafted covering all edge cases, error conditions, and security implications. 4. **Review, objection, and iteration**: The draft is reviewed publicly; vendors raise objections and the spec is revised until consensus is reached. 5. **Implementation and testing**: Browser vendors implement the feature behind a flag; a shared test suite verifies all implementations behave identically. 6. **Finalization**: Once multiple independent implementations pass the tests, the standard is finalized (W3C Recommendation, TC39 Stage 4, or a WHATWG living standard update). ## The Lifecycle of Web Standards Features 1. **Proposal**: Someone identifies a problem and writes it down to find out whether others share it. 2. **Incubation**: The idea is stress-tested through open discussion; many proposals die here if they're too niche or no solution satisfies everyone. 3. **Specification**: A formal spec is written that turns vague concepts into exact, implementable rules. 4. **Interoperability testing**: The W3C Web Platform Tests suite verifies that every browser implements the feature identically. 5. **Finalization**: Multiple passing implementations mean the feature ships to users as part of the baseline web platform. 6. **Deprecation**: Superseded or problematic features are marked for discontinuation; removal from browsers is slow due to backwards-compatibility obligations. ## Key Principles of Web Standards - **Openness**: Standards are developed in the open and implemented royalty-free by anyone. - **Accessibility**: The web is designed to be usable by everyone, with accessibility built into HTML, CSS, and browser behavior. - **Interoperability**: A page built to standard should behave identically across all browsers and operating systems. - **Backwards compatibility**: New capabilities are layered on top of existing ones so old pages continue to work in modern browsers. - **Privacy and security**: New APIs that could expose user data face significant scrutiny; the platform protects users by default. - **Layering**: HTML handles structure, CSS handles presentation, and JavaScript handles behavior — each layer works independently. - **Progressive enhancement**: Features must work for everyone first, then improve for users with more capable browsers or devices.