HTTP, Forms, and Client-Server Communication
The HTTP, Forms, and Client-Server Communication domain tests how browsers and servers exchange data: request methods, status codes, headers, caching, cross-origin rules and form submission.
Methods and status codes
GET is safe and idempotent and should never change state; PUT and DELETE are idempotent; POST is neither. Expect 200 OK, 201 Created with a Location header, 204 No Content, 301 permanent and 302/307/308 redirects, 304 Not Modified for a conditional request, 400 bad request, 401 unauthenticated, 403 authenticated but forbidden, 404, 405 wrong method, 409 conflict, 422 validation failure, 429 rate limited, plus 500/502/503/504 on the server side.
Headers and caching
Content-Type describes the body; Accept states what the client wants; Authorization carries credentials. Cache-Control: max-age=3600 allows reuse, no-cache forces revalidation, no-store forbids storage. ETag paired with If-None-Match produces a cheap 304.
CORS and cookies
Cross-origin reads need Access-Control-Allow-Origin. Non-simple requests (custom headers, PUT, JSON Content-Type) trigger an OPTIONS preflight. Allow-Origin: * cannot be combined with credentials. Cookies are sent automatically on matching requests, so mark them HttpOnly, Secure and SameSite.
Forms
method="get" appends fields to the URL; method="post" sends them in the body. Default encoding is application/x-www-form-urlencoded; file uploads need enctype="multipart/form-data". Native attributes (required, type="email", pattern, minlength) validate before submission unless the form sets novalidate.
Worked example
const res = await fetch('/api/login', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(creds), credentials: 'include' }); if (!res.ok) throw new Error(res.status); - fetch rejects only on network failure, so res.ok must be checked.
Traps
Assuming fetch throws on 404, sending state changes over GET, and confusing 401 with 403.