HTTP and HTTPS

HTTP is an application-layer protocol for exchanging requests and responses between clients and servers. It commonly underlies a browser opening a page, a mobile application retrieving a profile, or a frontend submitting a form to a backend.

HTTPS uses the same HTTP over a TLS-secured connection. HTTP defines request and response meaning, while HTTPS protects the channel through encryption, server authentication, and protection against data tampering in transit.

This is foundational for QA. Understanding HTTP and HTTPS supports confident investigation of networking, authorization, redirects, cookies, login-form security, and browser behavior.

How it works

An HTTP client sends a request containing several important parts:

→A method, such as GET, POST, PUT, or DELETE
→A resource address
→Headers
→Sometimes a request body

The server receives and processes the request, then returns a response with a status code, headers, and body.

HTTP itself is stateless: it does not retain state between requests. A server does not remember a client simply because it made a previous request. Cookies, tokens, sessions, or application-side data usually maintain state.

From a QA perspective, HTTPS works similarly, but first establishes a secure TLS connection before transmitting HTTP data. The client checks the server certificate and negotiates a secure channel. HTTP requests and responses are then exchanged.

→HTTP defines client-server communication rules.
→HTTPS combines HTTP with TLS channel protection.

What HTTPS changes

QA engineers should understand three practical properties.

First, confidentiality: outsiders should not read transmitted data as plaintext. This is particularly important for usernames, passwords, tokens, payment data, and personal information.

Second, integrity: data should not be silently modified between client and server in either direction.

Third, server authentication: the client must confirm it is communicating with the intended server rather than an impostor.

Avoid overestimating HTTPS. It does not automatically secure a system. Excessive backend data disclosure, incorrect permissions, business-logic vulnerabilities, and insecure direct object references remain possible. HTTPS protects the channel rather than the entire product.

What matters to QA

HTTP and HTTPS are practical diagnostic tools beyond networking theory.

DevTools, Charles, Proxyman, Postman, and gateway logs essentially expose the HTTP layer. QA should be able to interpret the basics:

→Which request was sent
→Which URL it targeted
→Which method it used
→Which headers were included
→What the body contained
→Which status was returned
→What the response contained
→Whether a redirect occurred
→Whether authorization failed
→Whether the problem lies specifically in HTTPS

Failures can occur in different places.

For example, “Unable to sign in” may result from a server 401, frontend mishandling of 200, HTTP being used instead of HTTPS, a cookie failing to persist because Secure is not set, incorrect certificate or proxy configuration in the test environment, or an HTTP/HTTPS redirect loop. The visible login error is the same, but the failure points differ.

What to check

→Whether HTTP is redirected to HTTPS
→Whether the site opens without browser certificate warnings
→Whether mixed content occurs when an HTTPS page loads insecure HTTP resources
→Whether sensitive cookies have Secure and, where needed, HttpOnly flags
→Whether tokens or sensitive data leak through URLs, logs, or redirects
→Whether required scenarios work consistently behind reverse proxies, CDNs, and in test environments
→Whether CORS, proxies, or certificates break API calls

For API QA, 200 OK alone does not establish security or correct transport behavior. Equally, a connection problem does not necessarily mean business logic is wrong.

Practical example

Consider a login form. The user enters an email and password, the browser POSTs to the authorization endpoint, and the server validates the data and returns a token or session cookie.

QA should check that:

→The form sends its request to an HTTPS endpoint.
→The password is absent from the query string.
→The session or cookie is established correctly after login.
→The cookie has the required security flags.
→An old HTTP link redirects correctly to HTTPS.
→Authorization survives the redirect.
→The browser shows no certificate warning.

Key takeaways for QA engineers

→HTTP defines the format and meaning of request-response exchanges.
→HTTPS is HTTP over TLS: a protected communication channel.
→HTTPS provides encryption, data integrity, and server authentication.
→HTTPS does not replace testing of business logic, permissions, and application security.
→Investigating defects requires examining the network layer alongside the screen.