Innomerc Learn
English is the default.
Internet & Networking

HTTP and HTTPS Explained

Watch a browser send a request and receive a response, then place that exchange inside a protected channel.

Foundational6 min explorationReviewed
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

HTTP is a request-and-response protocol. A browser asks for a resource; a server replies with a status, headers and often a body. HTTPS protects that HTTP exchange with TLS so intermediaries cannot normally read or alter the protected content.

The protection applies to the connection with the named service. A fraudulent shop can still have HTTPS. A secure transport indicator does not promise that the business is honest or that everything on the page is safe.

Technical explanation

Under the hood

A request includes a method, a target and headers; some requests include a body. A response includes a status and headers and may include content. HTTP/1.1, HTTP/2 and HTTP/3 share semantics while using different wire representations and transport behavior.

HTTPS commonly uses TLS over TCP for HTTP/1.1 and HTTP/2. HTTP/3 uses QUIC with TLS integrated into its handshake. Intermediaries may terminate TLS and establish another connection upstream; the diagram’s one server is a simplified trust boundary.

Practitioner explanation

Practitioner perspective

Document every TLS termination point and where plaintext exists inside infrastructure. A CDN, reverse proxy and application can see different client identity and address fields. Forwarded headers are not trustworthy unless their source and handling are controlled.

Investigate requests using method, route, response status, identity, timing and a correlation identifier. Avoid logging authorization headers or sensitive bodies. HTTPS does not correct SQL injection, broken authorization or application-side data leakage.

TLS

A locked capsule travels through a tube between endpoints; an outside observer cannot read its contents.

HTTP is a request-and-response protocol. A browser asks for a resource; a server replies with a status, headers and often a body. HTTPS protects that HTTP exchange with TLS so intermediaries cannot normally read or alter the protected content.

Illustrated analogy · Select the image to enlarge
See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

HTTP response map

Select a status and watch where the request is handled.

Steps1. GET guide 2. Forward 3. 200 4. 200
Click a box or choose its name to learn what it means.
BrowserReadyGatewayReadyAPI serviceReadyBrowserReadyGatewayReadyAPI serviceReady
Ready to trace200 OK
Before you start · 4 steps200 OK

A successful request returns a representation.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Browser

    The program you use to open websites.

    Example: Your browser requests a web page and displays the response.

  • Gateway

    A system between a client and services that routes requests and may apply checks.

    Example: It may reject a request over a configured rate limit before it reaches a service.

  • API service

    A system that accepts structured requests from other software and returns results.

    Example: A weather service returns the forecast requested by an app.

200 OK

A successful request returns a representation.

  1. Browser Gateway: GET guide. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 200. A successful request returns a representation. Example response: Representation returned
  4. Gateway Browser: 200. The gateway returns the response to the client.

201 Created

Creation succeeds; the Location header can identify the new resource.

  1. Browser Gateway: POST order. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 201. Creation succeeds; the Location header can identify the new resource. Example response: Location: /orders/42
  4. Gateway Browser: 201. The gateway returns the response to the client.

204 No Content

The operation succeeds without response content.

  1. Browser Gateway: DELETE item. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 204. The operation succeeds without response content. Example response: No response body
  4. Gateway Browser: 204. The gateway returns the response to the client.

301 Moved Permanently

The client learns a permanent redirect; method handling requires care.

  1. Browser Gateway: GET old URL. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 301. The client learns a permanent redirect; method handling requires care. Example response: Location: /new
  4. Gateway Browser: 301. The gateway returns the response to the client.

400 Bad Request

The server rejects malformed input without leaking internals.

  1. Browser Gateway: Malformed request. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 400. The server rejects malformed input without leaking internals. Example response: Safe client error
  4. Gateway Browser: 400. The gateway returns the response to the client.

401 Unauthorized

The private endpoint requires valid authentication credentials.

  1. Browser Gateway: No valid credentials. The request reaches the edge.
  2. Gateway Browser: 401. The private endpoint requires valid authentication credentials. Example response: WWW-Authenticate

403 Forbidden

The server refuses the operation despite understanding the request.

  1. Browser Gateway: Other user’s record. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 403. The server refuses the operation despite understanding the request. Example response: No protected body
  4. Gateway Browser: 403. The gateway returns the response to the client.

404 Not Found

The server cannot find the resource or chooses not to disclose it.

  1. Browser Gateway: Unknown path. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 404. The server cannot find the resource or chooses not to disclose it. Example response: Resource unavailable
  4. Gateway Browser: 404. The gateway returns the response to the client.

429 Too Many Requests

This example limiter asks the client to wait; retry guidance is policy-specific.

  1. Browser Gateway: Request burst. The request reaches the edge.
  2. Gateway Browser: 429. This example limiter asks the client to wait; retry guidance is policy-specific. Example response: Retry-After: 30

500 Server Error

An unexpected server failure is recorded privately, not exposed as a stack trace.

  1. Browser Gateway: Valid request. The request reaches the edge.
  2. Gateway API service: Forward. This example passes the edge checks.
  3. API service Gateway: 500. An unexpected server failure is recorded privately, not exposed as a stack trace. Example response: Safe error response
  4. Gateway Browser: 500. The gateway returns the response to the client.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Browser request

GET /guide asks the application for a resource.

1 / 4

Takeaway HTTP defines the exchange; it does not inherently encrypt it.

Read every step without animation

HTTP journey

  1. Browser request. GET /guide asks the application for a resource.
  2. Network. The HTTP message has no TLS protection in this example.
  3. Application. The application selects the resource.
  4. Response. 200 OK carries headers and the page body back.

HTTP defines the exchange; it does not inherently encrypt it.

HTTPS journey

  1. TLS connection. The browser establishes a protected connection and checks the server identity.
  2. Encrypted request. HTTP request content travels inside the protected channel.
  3. Application. The endpoint processes the decrypted request.
  4. Encrypted response. The response is protected on its return journey.

Transport protection ends at the TLS endpoint.

Explore deeper: additional experiment
Change an input. Inspect the consequence.

Follow a private request through the network

TLS identity policy response

The protected request reaches the service, passes the modeled checks and returns a response. Each boundary has a separate job.

A local teaching model with fictional inputs. It does not test a live system.

Attack view

On an unprotected HTTP path, an intermediary may observe or modify application data. HTTPS counters that class of transport attack when certificate validation succeeds; it does not repair a malicious endpoint.

Defender view

  • Serve the application over HTTPS and redirect HTTP appropriately.
  • Protect cookies and validate application input and authorization independently.
  • Apply HSTS only with an operational plan for the covered hostnames.

Common mistakes

  • HTTPS does not mean a website is legitimate.
  • HTTP/3 does not use TCP for its transport.

Check your understanding

What can a malicious site with a valid HTTPS connection still do?
Active recall: explain this idea in 30 seconds

HTTP is a request-and-response protocol. A browser asks for a resource; a server replies with a status, headers and often a body. HTTPS protects that HTTP exchange with TLS so intermediaries cannot normally read or alter the protected content.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Technology fundamentals

Back to topic