---
{
  "title": "HTTP and HTTPS",
  "summary": "Understand HTTP requests, methods, responses, and status codes while separating web semantics from encryption and application authorization.",
  "topic": "networking",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "IETF: TLS 1.3 specification",
      "url": "https://www.rfc-editor.org/rfc/rfc8446.html"
    },
    {
      "title": "IETF: HTTP Semantics, RFC 9110",
      "url": "https://www.rfc-editor.org/rfc/rfc9110.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Requests have meaning

HTTP defines semantics for requests and responses between clients and servers. A request identifies a target and a method, carries headers, and may include content. A response includes a status code, headers, and sometimes content. These elements help the participants interpret what operation is requested and what happened.

HTTP versions differ in how messages are transported and represented. Avoid assuming every HTTP exchange is a plain-text message over TCP: HTTP/3 uses QUIC. [[web-architecture]] provides the broader picture of browsers, applications, and intermediaries.

## One click can create many exchanges

Imagine a fictional learner opens an academy dashboard. The browser might request a document, scripts, styles, images, and API data. A successful document response does not prove that every dependent request succeeded.

If a progress widget is empty, inspect the relevant API exchange instead of assuming the entire website is unreachable. The document could load while the API rejects an expired session or returns an application error. [[sessions-and-cookies]] explains one way web applications maintain account context.

For an investigation, record which request you mean. “The website returned an error” is less useful than identifying the target, method, time, and relevant response.

## Methods express intended behavior

Methods such as GET and POST have defined semantics. GET is intended for retrieval and is defined as safe in the HTTP sense: the client is not requesting a state-changing operation. That does not guarantee every application implements it correctly or that a request has no incidental effects such as logging.

Suppose the academy puts an account-deletion action behind a GET link. Calling it a normal page request does not make that design appropriate. Protocol semantics should inform application behavior rather than excuse a mismatch.

## A status is a clue with context

Status codes group outcomes, including successful processing, redirection, client-related errors, and server-related errors. A code needs the application context. A successful HTTP response can still contain a business-level rejection or incomplete result.

Similarly, an authorization-related response does not identify the underlying cause by itself. The learner might lack the required role, use an expired session, or request an unavailable resource. [[http-status-codes]] develops interpretation without treating one number as a full diagnosis.

## HTTPS protects a connection

HTTPS uses a protected transport arrangement with TLS. It helps secure data in transit and validate the endpoint under the applicable trust model. It does not decide which learner may read which record, make uploaded files harmless, or prevent every application vulnerability.

For a safe exercise, inspect your own browser's requests to a training application you control. Choose one request and explain its target, method, status, and account context without sharing secret headers. Continue with [[tls]] for connection protection and [[authorization]] for the permission decision that HTTP alone cannot supply.