Coursify

HTTP Fundamentals: Identifying the False Statement

HTTP Fundamentals: Identifying the False Statement

Verified Sources
Nov 4, 2026

HTTP is the application-layer protocol used to transfer hypermedia documents on the Web. Conceptually, HTTP is defined as communicating using a request/response exchange, typically over a transport protocol such as TCP (and commonly over TLS via HTTPS). 2

To evaluate the four statements, map each one to what HTTP actually does:

[Callout—pro tip] A good test is: Is the claim about the transport, the payload/representation, or “storage” semantics? This question hides one option that blurs HTTP’s role with URL/query semantics.

Key terms for this section: HTTP , TCP , URL , HTTP method HEAD.

Footnotes

  1. RFC 9110 “HTTP Semantics” (overview of HTTP and message-based application protocol) - https://www.rfc-editor.org/rfc/rfc9110 - Defines HTTP semantics and request/response model. ↩

  2. RFC 9111 “HTTP Caching” (context for HTTP over transport, and general HTTP framework) - https://www.rfc-editor.org/rfc/rfc9111 - Provides HTTP protocol semantics including caching behavior. ↩

HTTP request/response basics (web protocol overview)

(i) “HTTP runs over TCP”

This statement is true in the standard Web stack. HTTP is an application protocol that uses TCP for reliable delivery; HTTPS commonly runs HTTP over TLS, which itself typically runs over TCP. 2

Footnotes

  1. RFC 9110 “HTTP Semantics” (overview of HTTP and message-based application protocol) - https://www.rfc-editor.org/rfc/rfc9110 - Defines HTTP semantics and request/response model. ↩

  2. RFC 9111 “HTTP Caching” (context for HTTP over transport, and general HTTP framework) - https://www.rfc-editor.org/rfc/rfc9111 - Provides HTTP protocol semantics including caching behavior. ↩

(ii) “HTTP describes the structure of web pages”

This statement is effectively true in the exam sense, but with a nuance: HTTP does not “define page structure” by itself—HTML (and related markup) defines the structure, while HTTP transports and serves those representations (e.g., an HTML document). However, since pages are delivered as HTTP responses (often with Content-Type like text/html), the intent of the statement matches typical curriculum phrasing: HTTP carries the representations that constitute web pages.

Keywords: MIME type , Content-Type , HTML

Footnotes

  1. MDN Web Docs: MIME type / Content-Type explanation - https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types - Explains media types and how HTTP identifies representations like text/html. ↩

(iii) “HTTP allows information to be stored in a URL”

This is the FALSE statement. HTTP does not provide a general mechanism to “store” information in a URL as a persistent data store.

While a URL can include data in the query component (e.g., ?id=123), that is part of addressing/parameterization—not HTTP’s “storage” capability. URLs can be constructed to include values, and servers can interpret those values, but HTTP is not a database that stores arbitrary data into the URL. Instead, HTTP requests/ responses exchange data; persistence mechanisms (like cookies, server-side storage) handle longer-term state. 2

Keywords: Query string , State management , Cookie

Footnotes

  1. RFC 3986 “URI Generic Syntax” (defines URL/URI components like query) - https://www.rfc-editor.org/rfc/rfc3986 - Specifies how the query component carries parameters in a URI. ↩

  2. RFC 6265 “HTTP State Management Mechanism” (cookies for state persistence) - https://www.rfc-editor.org/rfc/rfc6265 - Defines cookies as the common mechanism for remembering state. ↩

This statement is true. A client can check whether a link target exists (and is accessible) by issuing an HTTP request such as HEAD (headers only) or GET (headers + body) and observing status codes (e.g., 200 OK, 404 Not Found). That is a common approach to validating link targets. 2

Footnotes

  1. RFC 7231 “HTTP/1.1 Semantics and Content” (status codes and request methods like HEAD) - https://www.rfc-editor.org/rfc/rfc7231 - Documents HTTP methods and status-code meanings (e.g., 404). ↩

  2. MDN Web Docs: HTTP status codes (e.g., 200, 301, 404) - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status - Provides practical interpretation of common HTTP status codes for link checking. ↩

How HTTP can test link validity (existence/proxy check)

  1. 1
    Step 1

    Issue an HTTP request to the URL found in the hyperlink, typically using the HEAD method to avoid downloading the full resource.

  2. 2
    Step 2

    Interpret server responses: 200200-series usually indicates success, while 404404 commonly indicates the target is not found.

  3. 3
    Step 3

    If you receive a redirect (e.g., 301/302/307301/302/307), decide whether to follow it; also consider that some servers may return 403403 for access restrictions.

  4. 4
    Step 4

    "Batch-check many links by reusing the same request logic for each target URL."

    Keywords: HTTP status code , HEAD , Redirect

Exam-trap warning

“Stored in a URL” is the trap phrase. URL query parameters can contain data, but HTTP is not a “store” that writes data into URLs; it exchanges requests/responses and relies on other state mechanisms for persistence.

Fast elimination strategy

If a statement describes something like persistence/storage semantics, check whether it confuses HTTP with URL parameterization or with cookies/server-side storage.

Truth value check for the four statements

Based on typical Web protocol interpretation in networking courses.

Where each statement fits in the Web stack

HTTP over TCP/TLS

Transport layer

HTTP messages are carried over TCP; HTTPS adds TLS on top of TCP. 2"

Footnotes

  1. RFC 9110 “HTTP Semantics” (overview of HTTP and message-based application protocol) - https://www.rfc-editor.org/rfc/rfc9110 - Defines HTTP semantics and request/response model. ↩

  2. RFC 9111 “HTTP Caching” (context for HTTP over transport, and general HTTP framework) - https://www.rfc-editor.org/rfc/rfc9111 - Provides HTTP protocol semantics including caching behavior. ↩

HTTP transports page representations

Application layer

HTTP serves resources like HTML documents, paired with Content-Type. "

Footnotes

  1. MDN Web Docs: MIME type / Content-Type explanation - https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types - Explains media types and how HTTP identifies representations like text/html. ↩

Query parameters vs storage

URL semantics

URLs may include parameter values, but HTTP is not a mechanism to store data into URLs. 2"

Footnotes

  1. RFC 3986 “URI Generic Syntax” (defines URL/URI components like query) - https://www.rfc-editor.org/rfc/rfc3986 - Specifies how the query component carries parameters in a URI. ↩

  2. RFC 6265 “HTTP State Management Mechanism” (cookies for state persistence) - https://www.rfc-editor.org/rfc/rfc6265 - Defines cookies as the common mechanism for remembering state. ↩

Link validity checking

Request/response probing

Use HEAD/GET and status codes to probe link targets. 2"

Footnotes

  1. RFC 7231 “HTTP/1.1 Semantics and Content” (status codes and request methods like HEAD) - https://www.rfc-editor.org/rfc/rfc7231 - Documents HTTP methods and status-code meanings (e.g., 404). ↩

  2. MDN Web Docs: HTTP status codes (e.g., 200, 301, 404) - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status - Provides practical interpretation of common HTTP status codes for link checking. ↩

Clarifications (to avoid common misconceptions)

Quick recall

1 / 4
Question · Term

Which statement is FALSE in the given options?

Click to reveal
Answer · Definition

(iii) HTTP allows information to be stored in a URL

Knowledge Check

Question 1 of 3
Q1Single choice

Which one of the following statements is FALSE?

Explore Related Topics

1

Distinguishing IPv6 from IPv4: Address Length

2

TCP/IP vs OSI: Which Abstraction Layer Is Missing?

3

ICMP Validity Check: Which Statements Could Be Valid?

Browse all research articles