What Is HTTP: Methods, Headers, and HTTPS

HTTP is a request and a response, nothing more exotic

HTTP (Hypertext Transfer Protocol) is how a client asks a server for something and gets an answer. One request looks like this:

POST /v1/orders HTTP/1.1
Host: api.shop.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{"sku":"abc","qty":2}

Four parts matter for API work:

• Method – the verb (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS). GET and HEAD should not change server state. PUT is idempotent replace; POST is “process this,” often create. Gateways that apply rules by method are matching this field, not the path alone.
• Target – the path (/v1/orders) plus query string (?limit=10). The host sits in the Host header (HTTP/1.1) or in the URL.
• Headers – name/value metadata. This is where almost every authentication scheme lives: Authorization, X-API-Key, Content-Type.
• Body – optional payload. GET and HEAD should not have one. Authentication almost never belongs here; bodies get logged more often than people admit.

The response is a status code, headers, and a body. 2xx succeeded. 4xx is the client’s problem (401 missing/wrong credentials, 403 authenticated but not allowed, 404 missing, 429 rate-limited). 5xx is the server’s problem. A proxy that returns 403 with requestrocket-proxy-code: proxy-access-denied is using HTTP’s existing status line to carry a policy decision, not inventing a parallel protocol.

HTTPS is HTTP inside TLS

TLS (the successor to SSL) wraps the TCP connection before any HTTP bytes are sent. It provides confidentiality and integrity for headers and body. Without it, Basic Auth is a password in the clear, an API key is a secret in the clear, and a JWT is a bearer token in the clear.

https:// on a target base URL is not a style choice. RequestRocket’s target schema requires an HTTP(S) URL; pointing a proxy at http:// for anything that carries credentials is how you undo AES-256 at rest and every grant type in this series.

HTTPS does not authenticate the caller. The certificate authenticates the server to the client (and, with mTLS, optionally the client to the server). Application identity – keys, Basic, OAuth access tokens, JWTs – still lives in HTTP headers inside that tunnel.

Where a reverse proxy sits

A reverse proxy terminates the caller’s HTTP request, applies policy, then opens a second HTTP request to the upstream API.

Caller                     Gateway                      Upstream
  |-- HTTPS request ------->|                             |
  |   method, path, headers |  check proxy credential     |
  |                         |  evaluate rules             |
  |                         |-- HTTPS request ----------->|
  |                         |   (target credential added) |
  |                         |<-- response ----------------|
  |<-- response + extra hdrs|                             |

Two hops, two credentials, one caller-visible URL. The caller never sees the upstream Authorization value. The upstream never sees the caller’s proxy key. That split is the operational reason to care about HTTP at this level of detail: methods, paths, and headers are the fields rules match, and they are the fields you must not log when they contain secrets.

Headers you should treat as radioactive

Authorization, Cookie, X-API-Key, and anything you configured as credentialSecret.key are credentials. They belong in the encrypted credential record (AES-256-GCM), not in application logs. Query-string credentials (?api_key=) are the same secret with a worse leakage profile.

Next steps

The schemes that fill these headers are the rest of this series: JWT, OAuth 2.0, Basic Auth, API keys, token exchange. Configuring them as credentials is in the credentials guide. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes.