Sources

S1 — MDN: Overview of HTTP

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview

  • authority: official-docs
  • supports: Defines HTTP as a client-server protocol for fetching resources, and explains that browsers and servers communicate by exchanging requests and responses.
  • key-fact: "HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser."

S2 — RFC 9110: HTTP Semantics

URL: https://www.rfc-editor.org/rfc/rfc9110.html

  • authority: official-docs
  • supports: Defines the core request/response model, methods, status codes, and header fields.
  • key-fact: "Each message is either a request or a response. A client constructs request messages that communicate its intentions and routes those messages toward an identified origin server. A server listens for requests, parses each message received, interprets the message semantics in relation to the identified target resource, and responds to that request with one or more response messages."

S3 — MDN: HTTP messages

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages

  • authority: official-docs
  • supports: Describes the structure of HTTP requests and responses, including start-line, headers, and body.
  • key-fact: "HTTP messages are the mechanism used to exchange data between a server and a client in the HTTP protocol. There are two types of messages: requests sent by the client to trigger an action on the server, and responses, the answer that the server sends in response to a request."

S4 — MDN: GET request method

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET

  • authority: official-docs
  • supports: Defines GET as the method for retrieving a resource.
  • key-fact: "The GET HTTP method requests a representation of the specified resource. Requests using GET should only be used to request data and shouldn't contain a body."

S5 — MDN: POST request method

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/POST

  • authority: official-docs
  • supports: Defines POST as the method for submitting data to a server.
  • key-fact: "The POST HTTP method sends data to the server. The type of the body of the request is indicated by the Content-Type header."

S6 — MDN: HTTP response status codes

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status

  • authority: official-docs
  • supports: Defines the five classes of status codes and what each class means.
  • key-fact: "HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes: Informational responses (100 – 199), Successful responses (200 – 299), Redirection messages (300 – 399), Client error responses (400 – 499), Server error responses (500 – 599)."

S7 — MDN: 200 OK

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/200

  • authority: official-docs
  • supports: Defines the 200 OK status code as a successful response.
  • key-fact: "The HTTP 200 OK successful response status code indicates that a request has succeeded. A 200 OK response is cacheable by default."

S8 — MDN: 404 Not Found

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404

  • authority: official-docs
  • supports: Defines the 404 Not Found status code as a client error.
  • key-fact: "The HTTP 404 Not Found client error response status code indicates that the server cannot find the requested resource."

S9 — MDN: 500 Internal Server Error

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/500

  • authority: official-docs
  • supports: Defines the 500 Internal Server Error status code as a server error.
  • key-fact: "The HTTP 500 Internal Server Error server error response status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request."

S10 — Chrome DevTools: Inspect network activity

URL: https://developer.chrome.com/docs/devtools/network

  • authority: official-docs
  • supports: Explains how to open the Network panel and inspect individual requests and responses.
  • key-fact: "The Network panel logs all network activity in the Network Log. Each row of the Network Log represents a resource... Click a resource to learn more information about it. The Headers tab is shown. Use this tab to inspect HTTP headers."

S11 — Chrome DevTools: Network panel overview

URL: https://developer.chrome.com/docs/devtools/network/overview

  • authority: official-docs
  • supports: Describes the Network panel's default columns and request details.
  • key-fact: "The Requests table displays the following columns by default: Name, Status, Type, Initiator, Size, and Time."

S12 — MDN: What is a URL?

URL: https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_URL

  • authority: official-docs
  • supports: Names each part of a URL — scheme, authority (domain and port), path, parameters, anchor — and says which parts reach the server.
  • key-fact: "It is worth noting that the part after the #, also known as the fragment identifier, is never sent to the server with the request." And: "The port indicates the technical "gate" used to access the resources on the web server. It is usually omitted if the web server uses the standard ports of the HTTP protocol (80 for HTTP and 443 for HTTPS)."

S13 — MDN: HTTP request methods

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods

  • authority: official-docs
  • supports: Lists the request methods and classifies each as safe, idempotent, and/or cacheable.
  • key-fact: "Each request method has its own semantics, but some characteristics are shared across multiple methods, specifically request methods can be safe, idempotent, or cacheable." The table marks GET safe/idempotent/cacheable, PUT and DELETE not safe but idempotent, and POST neither safe nor idempotent.

S14 — MDN: Redirections in HTTP

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections

  • authority: official-docs
  • supports: Explains how 3xx responses plus a Location header work, and distinguishes 301, 302, 307, and 308 by permanence and method handling.
  • key-fact: "Redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to. When browsers receive a redirect, they immediately load the new URL provided in the Location header. Besides the small performance hit of an additional round-trip, users rarely notice the redirection." The tables state 301/302 leave GET unchanged but "others may or may not be changed to GET", while 307 and 308 keep "Method and body not changed".

S15 — MDN: HTTP caching

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching

  • authority: official-docs
  • supports: Distinguishes private from shared caches, and explains that no-cache forces revalidation rather than forbidding storage.
  • key-fact: "If you do not want a response to be reused, but instead want to always fetch the latest content from the server, you can use the no-cache directive to force validation... the client will receive a 200 OK response if the requested resource has been updated, or will otherwise receive a 304 Not Modified response if the requested resource has not been updated."

S16 — MDN: Cross-Origin Resource Sharing (CORS)

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS

  • authority: official-docs
  • supports: Explains that CORS is a browser-enforced, header-based mechanism layered on the same-origin policy, including the preflight request.
  • key-fact: "Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources... For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts."

S17 — MDN: Using HTTP cookies

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies

  • authority: official-docs
  • supports: Describes Set-Cookie, the Cookie request header, and how the Domain and Path attributes scope which URLs a cookie is sent to.
  • key-fact: "The Domain and Path attributes define the scope of a cookie: what URLs the cookies are sent to... If the Set-Cookie header does not specify a Domain attribute, the cookies are available on the server that sets it but not on its subdomains. Therefore, specifying Domain is less restrictive than omitting it."

S18 — MDN: 403 Forbidden

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/403

  • authority: official-docs
  • supports: Defines 403 and distinguishes it from 401 and from 404.
  • key-fact: "The HTTP 403 Forbidden client error response status code indicates that the server understood the request but refused to process it. This status is similar to 401, except that for 403 Forbidden responses, authenticating or re-authenticating makes no difference."

S19 — MDN: HTTPS (glossary)

URL: https://developer.mozilla.org/en-US/docs/Glossary/HTTPS

  • authority: official-docs
  • supports: Defines HTTPS as HTTP over TLS encryption.
  • key-fact: "HTTPS (HyperText Transfer Protocol Secure) is an encrypted version of the HTTP protocol. It uses TLS to encrypt all communication between a client and a server."

S20 — MDN: Critical rendering path

URL: https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Critical_rendering_path

  • authority: official-docs
  • supports: Defines the critical rendering path as the sequence that turns HTML, CSS, and JavaScript into pixels, which is why some subresources block first paint.
  • key-fact: "The Critical Rendering Path is the sequence of steps the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen. Optimizing the critical render path improves render performance."