Telescope

HTTP Requests: Methods, URLs, Headers, Bodies, and Debugging

Learn how HTTP requests connect browsers and servers, including methods, URLs, parameters, headers, cookies, bodies, status codes, security, and debugging.

An HTTP request is a message sent by a client to a server to retrieve, submit, create, update, or delete information. HTTP is the application protocol commonly used for communication on the web.

A client is software that sends requests, such as a browser, mobile application, or command-line tool. A server receives requests, processes them, and returns responses. The requested data or service is a resource, and a server location that accepts a request is an endpoint.

The HTTP Request-Response Cycle

1. A client identifies an endpoint with a URL.
2. The client sends an HTTP request containing an HTTP method, URL information, headers, and sometimes a body.
3. The server selects a route or endpoint, validates the request, performs its work, and creates a response.
4. The client receives the response, which includes a status code and possibly headers and a response body.

For example, a browser may send a GET request when you open an article page. The server can respond with status 200 and HTML. JavaScript might then send another request for JSON data without loading a new page.

Anatomy of an HTTP Request

A request usually contains a request line, headers, and an optional request body. The request line identifies the intended operation and location.

POST /api/tasks?source=web HTTP/1.1
Host: example.com
Accept: application/json
Content-Type: application/json
Authorization: Bearer YOUR_TOKEN

{"title":"Review observations"}

Request line

The request line contains the HTTP method, path or URL, and HTTP version:

GET /api/articles/42 HTTP/1.1

The server uses the method and path to choose an endpoint. It then uses query parameters, headers, and the body to decide how to process the request.

Headers

A header is named metadata expressed as a field such as Accept: application/json. Headers can describe the body format, identify accepted response formats, carry authentication information, identify the client, or provide browser-origin information.

Request body

The request body is an optional payload. GET requests commonly place filters in the URL, while POST, PUT, PATCH, and file-upload requests commonly send data in the body. A body must be serialized into a format the server understands, and its format should be identified with the Content-Type header.

URLs, Paths, and Parameters

A URL is the address identifying a resource or endpoint. Consider this example:

https://example.com:8443/products/42?view=compact#reviews

• Protocol: https specifies the communication scheme.
• Host: example.com identifies the server.
• Port: 8443 identifies a network port. If omitted, the protocol's usual port is used.
• Path: /products/42 identifies a route or resource location.
• Query string: ?view=compact contains optional key-value parameters.
• Fragment: #reviews identifies a section within the returned resource. Browsers generally do not send the fragment to the server.

Route parameters and query parameters

A route parameter is a value embedded in a path pattern. In /products/42, 42 can be the product identifier for a route such as /products/:id.

A query parameter is an optional key-value pair after ?. Multiple parameters are separated by &:

GET /search?q=space%20telescope&page=2 HTTP/1.1

Here, q and page are query parameters used to search and paginate results. Query parameters are useful for filtering, sorting, searching, and selecting a representation of a resource.

URL encoding

URL encoding replaces characters that have special meanings or cannot safely appear in a URL. A space can become %20, and characters such as &, ?, and # need careful encoding because they delimit parts of a URL. Use a URL-encoding function or a tool option such as curl's --data-urlencode rather than manually guessing encodings.

HTTP Methods

An HTTP method is the verb indicating the intended operation. The method does not by itself grant permission; the server must still authenticate and authorize the request.

A method is safe when it is intended only for retrieving information and not for changing server state. A method is idempotent when repeating the same request is intended to produce the same final server state as making it once. Idempotence does not mean that every response is identical. POST is generally not idempotent because sending it twice may create two resources.

Common method examples

GET /api/articles/42 HTTP/1.1

POST /api/tasks HTTP/1.1
Content-Type: application/json

{"title":"Review observations"}

PATCH /api/tasks/42 HTTP/1.1
Content-Type: application/json

{"completed":true}

PUT commonly sends a complete replacement representation, whereas PATCH usually sends only fields to change. The exact behavior is defined by the server's API contract.

Request Data Formats

URL-encoded form data

Traditional HTML forms often use application/x-www-form-urlencoded. The fields are encoded as key-value pairs:

name=Sam&email=sam%40example.com

The server uses Content-Type to select the correct parser. A sign-up form might be configured as follows:

<form method="post" action="/signup">
  <input name="name">
  <input name="email" type="email">
  <button type="submit">Sign up</button>
</form>

Multipart form data

File uploads usually use multipart/form-data. The body is divided into parts, with each part carrying field metadata and content. Browsers generate the boundary that separates parts. Servers should validate file type, size, filename handling, and content rather than trusting the uploaded filename or browser-provided type.

JSON request bodies

APIs commonly accept JSON with Content-Type: application/json:

POST /api/tasks HTTP/1.1
Content-Type: application/json
Accept: application/json

{"title":"Review observations"}

If the client sends JSON without the correct Content-Type, the server may treat the body as plain text or fail to parse it. Conversely, setting a JSON content type does not make invalid JSON valid; the payload must also be serialized correctly.

Headers, Cookies, and Authentication

A cookie is small state data that a browser can send to a server in later requests. A session cookie usually contains an identifier that lets the server find session data. A token is a value presented by a client, often in the Authorization header. A username and password, API key, or other credential is authentication information used to prove identity. These mechanisms have different storage, expiration, and security properties.

Do not put passwords, API keys, session tokens, or other sensitive credentials in URLs. URLs can be stored in browser history, proxy records, analytics systems, and server logs. Prefer HTTPS and an appropriate protected header or request body, and redact secrets from logs.

Browser-Generated Requests

Browsers create requests when navigating to a page, loading images, stylesheets, scripts, and fonts, submitting an HTML form, or running JavaScript such as fetch(). One page load can therefore produce many requests.

A form's action specifies the destination URL, and its method specifies the method. A form with method="post" sends submitted fields in a POST request. If the method is omitted, the browser normally uses GET, placing form fields in the query string. The form's encoding setting controls how the fields are represented, especially for file uploads.

Responses and Status Codes

A response is the server message returned after handling a request. It can contain a status code, response headers, and a body such as HTML, JSON, or an empty body.

Status codes are grouped into classes: 2xx success, 3xx redirection, 4xx client-side request errors, and 5xx server-side errors.

Reliability and Security Basics

• Use HTTPS, which is HTTP protected by TLS encryption, to protect requests in transit.
• Validate incoming data on the server for required fields, types, ranges, permissions, and business rules.
• Sanitize data appropriately before using it in databases, HTML, commands, or other interpreters. Validation and output-safe handling address different risks.
• For cookie-authenticated form requests, protect against CSRF. Cross-site request forgery tricks a browser into sending an unwanted authenticated request. Common defenses include anti-CSRF tokens and appropriate cookie settings such as SameSite.
• Never expose secrets in query strings, logs, public client-side code, or error messages.
• CORS controls whether browsers permit JavaScript from one origin to read or send requests to another origin. It is enforced by browsers and must be configured by the server; changing only client-side code does not grant permission.

Reading and Debugging Requests

When a request fails, compare what you expected with what the client actually sent. Inspect the method, complete URL, path and query parameters, headers, request payload, response status, and response body.

Browser developer tools

1. Open the browser's developer tools and select the Network panel.
2. Perform the navigation, form submission, or JavaScript action again.
3. Select the relevant request.
4. Review its URL, method, request headers, cookies, payload, response status, response headers, response body, and timing.

A request that returns 404 usually has an incorrect path, identifier, host, or environment. A 405 indicates a method mismatch. A 400 or 422 points to malformed or invalid data. A 401 or 403 requires checking credentials, cookies, and permissions. A CORS error requires checking the server's allowed origins, methods, and headers, including any preflight OPTIONS request.

Using curl

The command-line HTTP client curl can make a request and display response headers:

curl -i "https://example.com/api/articles/42"

Send query parameters with URL encoding:

curl -G "https://example.com/search" --data-urlencode "q=space telescope" --data-urlencode "page=2"

Send JSON in a POST request:

curl -i -X POST "https://example.com/api/tasks" -H "Content-Type: application/json" -H "Accept: application/json" --data '{"title":"Review observations"}'

Send an authentication token in a header rather than the URL:

curl -i "https://example.com/api/account" -H "Authorization: Bearer YOUR_TOKEN"

Practical Request Patterns

Retrieve a public resource

GET /api/articles/42 HTTP/1.1
Accept: application/json

A successful server might return 200 OK and a JSON response body describing article 42.

Search with parameters

GET /search?q=space%20telescope&page=2 HTTP/1.1

The query string carries a search phrase and page number. Encoding preserves the intended value of the space.

Submit a sign-up form

POST /signup HTTP/1.1
Content-Type: application/x-www-form-urlencoded

name=Sam&email=sam%40example.com

The server should validate both fields before creating an account or returning validation errors.

Upload a file

A browser can send a profile avatar with a POST request using multipart/form-data. The server should enforce upload-size limits and validate the file rather than trusting client-provided metadata.

Exam-Relevant Notes

• The request is sent by the client; the response is returned by the server.
• The request line contains method, path or URL, and HTTP version.
• Content-Type describes the request body format; Accept describes preferred response formats.
• Route parameters are part of the path; query parameters follow ?.
• GET is safe and idempotent. POST is generally neither safe nor idempotent. PUT and DELETE are typically idempotent; PATCH is not necessarily idempotent.
• 401 concerns authentication, while 403 means access is refused despite the request being understood.
• HTTPS protects data in transit, but it does not replace server-side validation or authorization.

For a focused reference to this subject, see HTTP requests.