HTTP & HTTPS

By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site

The request and response protocol of the web; HTTPS is the same protocol, encrypted.

Also known as: Hypertext Transfer Protocol.

In HTTP (Hypertext Transfer Protocol), a client sends a request such as GET (fetch data) or POST (send data), and the server returns a status code (1xx information, 2xx success, 3xx redirect, 4xx client error, 5xx server error). HTTPS is HTTP over TLS (Transport Layer Security), on default port 443 instead of 80. TLS encrypts traffic and checks the site's certificate, but a padlock does not make a site trustworthy.

The intuition

Picture HTTP as an exchange of short, strictly formatted letters. The client writes a request: a method saying what it wants done, the path of the thing it wants, a few header lines of metadata and sometimes a body. The server writes back a response: a three-digit status code, its own headers and usually a body. Each exchange stands on its own, because the protocol is stateless: the server does not remember your previous request unless a cookie or a token in the headers reminds it. Plain HTTP sends those letters as postcards, readable and editable by every network that relays them, from the café Wi-Fi to your internet provider. HTTPS puts the same letters, in the same format, inside a sealed envelope called TLS (Transport Layer Security), and only after the server has proved who it is. Methods, headers, status codes and bodies mean exactly the same in both; HTTPS adds privacy and proof of identity around them.

The request's first line carries most of the meaning. The method states intent: GET and HEAD read, POST submits data for the server to process, PUT creates or replaces the resource at that path and DELETE removes one. RFC 9110, the standard for HTTP's semantics, calls GET, HEAD, OPTIONS and TRACE safe, because the client asks for no change, and counts PUT and DELETE, along with the safe methods, as idempotent: sending the same request twice has the same intended effect as sending it once. The first digit of the response code sorts the outcome into five classes, and headers such as Host, Content-Type and Location carry the rest. HTTPS inserts a handshake before any of this. In TLS 1.3 the two sides swap fresh key shares, from which each computes the same session keys without those keys ever crossing the network. The server then presents its certificate, signed by a certificate authority to bind a domain name to a public key, and signs the handshake with the matching private key. From then on every record is encrypted and integrity-checked.

The protection has clear limits. HTTPS hides the path, the headers, the cookies and the body, but an observer still sees the server's IP address, the port, the size and timing of the traffic and, unless both sides use the newer Encrypted Client Hello extension, the site's name, which the client otherwise sends unencrypted so the server knows which certificate to present. A certificate proves that someone controls the domain and says nothing about their honesty. The weakest moment is the first request: anything that starts as an http:// address, from an old link, a bookmark or a browser that does not upgrade automatically, leaves in plain text on port 80, where an attacker on the path can answer it before any redirect arrives. Practitioners therefore redirect every port 80 request with a 301 or 308, send the Strict-Transport-Security header so the browser switches to https:// by itself on later visits, automate certificate renewal, and add well-tested domains to the browsers' HSTS preload list to cover even the first visit.

Example

# status line and headers, then the body
curl -i https://example.com
curl -i -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"currency": "EUR", "quantity": 10}'

One order fetched over HTTPS, walked line by line

Parse the URL and pick the port. The client is asked for https://api.example.com/orders/1001. The scheme https means HTTP over TLS, the host is api.example.com, and no port is written, so the scheme's default applies: 443 (an http:// URL would default to 80). A DNS lookup returns 192.0.2.10, an address reserved for documentation that stands in for the real one here, and the client opens a TCP connection to 192.0.2.10 on port 443.
Run the TLS 1.3 handshake before any HTTP is sent. The client's ClientHello lists the cipher suites it supports, carries a fresh key share and names the site it wants, api.example.com. The server's ServerHello picks a suite and returns its own key share. From that moment both sides can compute the same keys, so everything the server sends next is encrypted: EncryptedExtensions with its remaining settings, its Certificate for api.example.com, a CertificateVerify signature over the handshake so far, made with the certificate's private key, and a Finished message. The client checks that the certificate names api.example.com, is within its validity dates and chains to an authority in its trust store, verifies the signature, then sends its own Finished.
Count the round trips. Assume a round-trip time of 40 ms and ignore the DNS lookup and the server's processing time. The TCP handshake costs 1 round trip, a full TLS 1.3 handshake costs 1 more, and the request and its response cost a third, so the response starts arriving after 3 × 40 = 120 ms. Over plain HTTP the TLS round trip disappears: 2 × 40 = 80 ms. HTTPS therefore adds 120 - 80 = 40 ms, and only when a connection is opened: a second request on the same connection costs 1 × 40 = 40 ms either way. The full TLS 1.2 handshake took 2 round trips, which would have given 4 × 40 = 160 ms.
Send the request, line by line. Inside the encrypted connection the client writes: GET /orders/1001 HTTP/1.1 Host: api.example.com Accept: application/json Line 1 is the request line: the method GET (a safe method, which asks to read and to change nothing), the target /orders/1001 and the protocol version. Host names the site, and HTTP/1.1 requires it because one IP address can serve many sites. Accept says JSON is the format the client wants back. Each line ends with a carriage return and a line feed, the empty line closes the header section, and this GET has no body, so the request is complete.
Read the response, line by line. The server answers: HTTP/1.1 200 OK Content-Type: application/json Content-Length: 42 Cache-Control: no-store Strict-Transport-Security: max-age=31536000; includeSubDomains {"id":1001,"currency":"EUR","quantity":10} The status line gives the version, the code 200 and the reason phrase OK. The first digit, 2, puts it in the success class; the phrase is only a label, and HTTP/2 drops it, which is why curl prints HTTP/2 200 on such connections. Content-Type says the body is JSON, Cache-Control: no-store tells browsers and proxies not to keep a copy of a private order, and the empty line separates the headers from the body.
Check Content-Length by counting bytes. The body holds three pairs: "id":1001 is 4 + 1 + 4 = 9 characters, "currency":"EUR" is 10 + 1 + 5 = 16, and "quantity":10 is 10 + 1 + 2 = 13. Add the two commas and the two braces: 9 + 16 + 13 + 2 + 2 = 42. Every character is ASCII, one byte each, so the body is 42 bytes and matches Content-Length: 42, which is how an HTTP/1.1 client knows where this message ends on a connection it may reuse.
Decode the HSTS header. max-age is counted in seconds, and 365 × 24 × 60 × 60 = 365 × 86,400 = 31,536,000, so max-age=31536000 means one 365-day year. For that year the browser rewrites any http://api.example.com link to https:// before sending anything, includeSubDomains extends the rule to every name under api.example.com, and each later response carrying the header restarts the count. The browser accepts the header only because it arrived over HTTPS; received over plain HTTP on port 80 it would be ignored.
Compare the same URL over plain HTTP. http://api.example.com/orders/1001 opens port 80 on 192.0.2.10 with no handshake, and the three request lines from step 4 cross the network as readable text. A correctly configured server replies only with a redirect: HTTP/1.1 301 Moved Permanently Location: https://api.example.com/orders/1001 Over HTTPS, an observer on the path saw 192.0.2.10, port 443, the name api.example.com from the ClientHello, and the sizes and timing of the packets. Over plain HTTP the same observer could read both the request and the redirect, and an attacker on the path could rewrite them, Location header included.

HTTPS leaves the HTTP request and response exactly as they are and wraps them in a connection that proves the server's name and hides and seals every line, at the cost of one extra round trip each time a new connection opens with a full TLS 1.3 handshake.

Common pitfalls

Stopping at the redirect. A 301 from http:// to https:// still lets the first plain request out on port 80, where an attacker on the same network can intercept it and keep the victim on plain HTTP, relaying the real site while reading and altering everything, the attack known as SSL stripping. Send Strict-Transport-Security on every HTTPS response so returning browsers never make that request, and consider the preload list for the first visit.
Switching HSTS on at full strength in one go. With includeSubDomains and a one-year max-age, every host under the domain must serve valid HTTPS for up to a year after each visit, including the forgotten intranet page or test box that never had a certificate, and, short of users clearing it themselves, a browser drops the rule only when it expires or when it receives max-age=0 over a valid HTTPS connection. Start with a short max-age such as 300 seconds, that is 300 / 60 = 5 minutes, raise it in steps once every subdomain is checked, and treat preloading as hard to reverse.
Turning off certificate checks to make an error go away. curl -k, requests.get(url, verify=False) and similar switches keep the encryption but drop the proof of who is at the other end, so anyone able to intercept the connection gets through. The usual real causes are a missing intermediate certificate on the server, a name that does not match the certificate, an expired certificate or a wrong clock on the client: fix the cause instead.
Believing HTTPS makes a URL private. The path and query string are encrypted on the wire, but they are still written to server and proxy logs, browser history and analytics tools, and can reach other sites in the Referer header when the page's referrer policy allows it. Keep tokens, passwords and personal data out of URLs and send them in headers or in the request body.
Ignoring what the method promises. Because GET is defined as safe, browsers, link previewers and crawlers feel free to fetch GET URLs on their own, so a link such as /orders/1001/cancel served on GET can cancel an order nobody meant to cancel. POST is neither safe nor idempotent, so a client that retries a timed-out POST can place the same order twice: use POST for changes and give each order a unique idempotency key, generated once and resent unchanged on every retry, so the server can recognise a repeat.

Frequently asked questions

What is the difference between HTTP and HTTPS?

HTTPS is HTTP carried inside a TLS connection, so the methods, headers, status codes and bodies are exactly the same. What differs is the wrapping: https:// addresses default to port 443 rather than 80, the server must prove with a certificate that it holds the name you asked for, and everything exchanged is encrypted and protected against tampering. Plain HTTP offers none of these protections, which is why major browsers flag plain HTTP pages as not secure.

How does HTTPS work?

When the connection opens, the browser and the server run a TLS handshake: they exchange fresh key shares to agree session keys, and the server sends a certificate for its domain and signs the handshake with the matching private key. The browser checks that the certificate names the site, is in date and chains to an authority it trusts. Only then does the ordinary HTTP request go out, encrypted with the session keys. With TLS 1.3 a full handshake costs one extra round trip when a new connection opens.

What ports do HTTP and HTTPS use?

By default HTTP uses TCP port 80 and HTTPS uses TCP port 443, which is why URLs rarely show a port. A URL can name another one explicitly, as in https://example.com:8443/, which is common for test and internal servers. The number is only a default: what makes a connection HTTPS is the TLS handshake, whatever the port. HTTP/3 runs over UDP rather than TCP, usually on port 443 as well, although a server may advertise another port.

What do HTTP status codes mean?

The first of the three digits gives the class: 1xx is informational, 2xx means success, 3xx a redirection, 4xx a problem with the request and 5xx a failure on the server. Everyday examples are 200 OK, 301 Moved Permanently, 304 Not Modified, 404 Not Found and 503 Service Unavailable. RFC 9110 requires a client that meets an unrecognised code to treat it as the x00 code of its class, so an unfamiliar 299 is handled like 200.

What is HSTS?

HSTS (HTTP Strict Transport Security) is a response header, such as Strict-Transport-Security: max-age=31536000; includeSubDomains, telling the browser to use only HTTPS for that site for the next max-age seconds, here 365 days. Until then the browser rewrites any http:// link to https:// before sending it and does not let the user click past a certificate error. The header only counts when it arrives over HTTPS, so a first visit stays exposed unless the domain is on the browsers' preload list.

Does HTTPS mean a website is safe?

Not on its own. HTTPS means your connection reaches whoever controls that domain name and that nobody in between can read or alter it. It says nothing about whether that party is honest: certificates that check only control of the domain can be obtained automatically and at no cost, so phishing sites show the same padlock or secure-connection icon as everyone else. Read the domain name itself before trusting the page.