HTTP and HTTPS

Why it matters

Many failures that look like application bugs are HTTP or HTTPS behaviour: users signed out at random because their next request reached a different server, a mobile app that cannot connect while the browser can, a checkout that stops working the day a certificate expires, a form that sends card details over plain HTTP. A tester who knows the model can name the cause and the team that owns it.

For users, HTTPS protects passwords, session cookies and personal data from anyone on the network path, such as the operator of a public Wi-Fi. For testers, HTTP is the layer every web and API test sits on.

Client and server: the request–response exchange

In HTTP the client always speaks first. It sends a request: a method such as GET or POST, a target such as /orders/1042, header fields and sometimes a body. The server waits for requests and answers each one with a response: a status code, header fields and usually a body.

Client and server are roles, not machines. A browser, a mobile app, curl and your automated tests are clients; so is a checkout service when it calls a payment API, although it is a server for its own users. Between them there are often intermediaries — proxies, load balancers, API gateways and CDNs (content delivery networks) — that forward a request or answer it from a cache. RFC 9110 calls the server that owns the resource the origin server, and the response you see was not always produced by it.

GET /orders/1042 HTTP/1.1
Host: shop.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 1042, "status": "shipped", "items": 3}

Try it: URL Parser Try it: HTTP Request Inspector

Stateless: every request stands alone

RFC 9110 defines HTTP as stateless: each request can be understood in isolation, and nothing in the protocol links your third request to your first. This is what lets a site spread requests over many servers behind a load balancer.

Applications that need continuity — a signed-in user, a cart, a multi-step form — build it on top: the client sends an identifier with every request, usually a cookie or an Authorization header, and the server looks up the matching state in its own storage. For a tester this turns into concrete test ideas:

• Refresh, a shared link and a second tab each send a new request, linked to the earlier steps only by what it carries, such as a cookie. Open step 3 of a checkout directly in a private window: the application should send you to sign-in or rebuild the step, not crash or show another user's data.
• If a server instance keeps session data in its own memory, the next request may reach an instance that has never seen you, and users lose their session or cart at random. Repeat the flow many times and ask how sessions are stored.
• The server must check on every request who sends it and what that user may do; it cannot rely on an earlier request. In your test environment, replay a request from your test account without its cookie or token: the server must refuse it.
• The server cannot tell a double click from two real orders. Submit a form twice quickly and count the orders created; preventing duplicates is the application's job, not HTTP's.

HTTPS: the same HTTP inside TLS

An https:// address means the HTTP messages travel inside a TLS (Transport Layer Security) connection, on port 443 by default instead of 80. The messages do not change; TLS adds three guarantees: confidentiality (nobody on the path can read them), integrity (altered bytes are detected and the connection fails) and authentication of the server (it really is the host in the address). A client can prove its identity with its own certificate too, which some service-to-service APIs require; this is called mutual TLS.

Before the first HTTP byte the two sides run a TLS handshake. It relies on a key pair: a public key that anyone may see and a private key that only the server keeps. Data signed with the private key can be checked with the public key, so a valid signature proves that the signer holds the private key. In TLS 1.3 the handshake takes one round trip: the client proposes keys and names the host it wants; the server answers with its choices, its certificate and a signature proving it holds the certificate's private key; both derive the same session keys, and only then is the request sent, encrypted.

A certificate binds a public key to host names, listed in its Subject Alternative Name field, and is signed by a certificate authority (CA). The server sends its certificate plus the intermediate certificates that link it to a root CA the client already trusts, because that root is stored in the operating system or browser. The client checks:

• Name: the host must be listed. A wildcard *.example.com covers shop.example.com but neither example.com nor api.shop.example.com.
• Dates: the certificate must be within its validity period. An expired certificate stops every client at once.
• Chain: every link up to a trusted root must be present. A missing intermediate is a classic defect: a desktop browser may fill the gap by itself while apps and scripts fail.
• What stays visible: an observer on the path still sees the IP address, the timing and size of messages and usually the host name, but not the path, query, headers, cookies or body.
• What HTTPS does not cover: it protects data in transit only. The server sees everything, and broken access control or injection flaws work just as well over an encrypted connection.

HTTP versions in brief

All current HTTP versions share the semantics defined in RFC 9110: methods, status codes and header fields mean the same everywhere, so a 404 is a 404 in every version. What changes is how the messages are carried:

• HTTP/1.1: plain-text messages. A connection is reused for many requests but in practice carries one at a time, so browsers open several connections per host. HTTP/1.0, which opened a new connection per request by default, is rarely seen today.
• HTTP/2: the same messages in binary frames, with many requests sharing one connection at once (multiplexing) and compressed headers. Header names are always lowercase, and browsers use HTTP/2 only over HTTPS.
• HTTP/3: the same model over QUIC, a transport that runs on UDP with TLS 1.3 built in, so a lost packet delays only the request it belongs to. Browsers often learn that a server offers it from an Alt-Svc response header, and fall back to HTTP/2 when a network blocks UDP.
• For testing: add the Protocol column to the Network panel in DevTools; Chrome shows http/1.1, h2 or h3 for each request. Behaviour should not depend on the version; when it does, suspect a proxy, a CDN setting or code that compares header names case-sensitively.

Worked example: an HTTPS check before a release

A shop is about to release a new sign-in page and an API for its mobile app. On staging, the tester checks https://staging.shop.example.com and https://api-staging.shop.example.com and records each result:

• http://staging.shop.example.com/login answers 301 with Location: https://staging.shop.example.com/login. Pass: plain HTTP only redirects.
• HTTPS responses carry Strict-Transport-Security: max-age=31536000. This HSTS header (RFC 6797) tells the browser to use only HTTPS for this host for a year; browsers ignore it when it arrives over plain HTTP. Pass.
• The certificate covers *.shop.example.com, chains to a trusted root and expires in 41 days. Not a defect, but the tester asks who renews it and how the team is warned.
• The Console reports blocked mixed content: the page loads a chat widget script from an http:// address, and browsers block insecure scripts on HTTPS pages, so the chat button is missing. Defect.
• The app cannot reach the API, although the same URL opens without a warning in a desktop browser. curl fails, and openssl s_client -connect api-staging.shop.example.com:443 -showcerts lists only the server's own certificate: the intermediate is missing. Defect, reported with this evidence:

Title:    api-staging sends an incomplete TLS chain; app and curl reject it
URL:      https://api-staging.shop.example.com/v1/health
Clients:  Android app 3.8.0 (staging build); curl on Ubuntu
curl:     curl: (60) SSL certificate problem: unable to get local issuer certificate
Android:  SSLHandshakeException: Trust anchor for certification path not found
Browser:  the same URL opens without a warning in desktop Chrome
Chain:    openssl s_client -showcerts shows 1 certificate (the server's own)
Expected: the server sends its certificate and the intermediate; clients connect
          with certificate verification on
Note:     not to be worked around with curl -k or a trust-all setting in the app

Try it: Redirect Checker Try it: Security Header Analyzer Try it: API Endpoint Tester

Frequently asked questions

References

• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018The TLS 1.3 handshake and record protocol that protect HTTPS traffic.
• RFC 6797: HTTP Strict Transport Security (HSTS)IETF · 2012The Strict-Transport-Security header that tells browsers to use HTTPS only for a host.
• Overview of HTTP — MDNMDN Web Docs (Mozilla)How HTTP works: a stateless client–server protocol in which the client sends a request and the server answers with a response message.