Methods

Overview

Every HTTP request begins with a method (also called a verb) that tells the server what action the client wants to perform on a resource. In HTTP challenges you often solve a task simply by sending the right method to the right endpoint. This lesson explains what HTTP methods are, what the common ones mean, and why swapping the method can change how a server responds — all practiced against provided, authorized challenge targets.

Learning objectives

• Identify the common HTTP methods and what each one means.
• Explain the difference between safe, idempotent, and state-changing methods.
• Describe why sending a different method than a browser normally would can reveal new behavior in a challenge.

Core concept

An HTTP method is the first token on the request line, for example GET /page HTTP/1.1. It communicates the client's intent: retrieve a resource, submit data, replace it, delete it, or just ask what is allowed. A server maps each method on each route to some handler; if a route handles more than one method, the same URL can behave completely differently depending on which verb you send. That gap between "what a browser sends by default" and "what the server actually accepts" is exactly what HTTP challenges probe.

How it works

The methods you will meet most often:

• GET — Retrieve a resource. Should be safe (no side effects) and is the default a browser uses for links.
• POST — Submit data to be processed (form submissions, creating records). Typically changes state.
• PUT — Replace a resource with the provided representation.
• PATCH — Apply a partial update to a resource.
• DELETE — Remove a resource.
• HEAD — Like GET but returns only headers, no body — useful for inspecting a resource cheaply.
• OPTIONS — Ask the server which methods a resource supports; the answer often comes back in an Allow header.

Two properties matter. A safe method (GET, HEAD, OPTIONS) is not meant to modify server state. An idempotent method (GET, HEAD, PUT, DELETE) produces the same result whether sent once or many times, while POST usually is not idempotent. Servers do not always enforce these conventions correctly, and that is where challenges live: a route might reveal extra data on a method it was never expected to receive.

Practical example

In an isolated challenge, a browser only ever loads a page with GET /profile, which shows a public view. Using a request tool you send OPTIONS /profile and the server responds with Allow: GET, POST, PUT. That tells you the route also accepts PUT. You then send PUT /profile with a small JSON body and the handler responds differently — perhaps returning an administrative view or accepting an update the UI never exposed. You did not exploit a memory bug or crack anything; you simply spoke a verb the developer forgot to restrict.

Cybersecurity relevance

Method handling is a frequent source of real access-control mistakes. Developers sometimes protect the GET view of a route but forget to apply the same authorization to POST, PUT, or DELETE, or they leave dangerous methods enabled on a server by default. Enumerating supported methods with OPTIONS, and testing whether a resource behaves differently under an unexpected verb, is a standard first step when assessing an authorized web target. On the defensive side, servers should explicitly allow only the methods a route needs and apply authorization consistently across all of them.

Common mistakes

• Only ever testing GET, because that is what the browser sends, and missing routes that behave differently under other verbs.
• Confusing safe with idempotent — GET is both, but PUT and DELETE are idempotent yet not safe.
• Forgetting to check OPTIONS/the Allow header, which often hands you the list of accepted methods for free.

Key takeaways

• The HTTP method states the client's intent; common verbs are GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS.
• Safe methods avoid side effects; idempotent methods give the same result whether sent once or many times.
• The same URL can behave differently per method, so changing the verb is a core HTTP-challenge technique — practiced only against authorized targets.

Check your understanding

• What is the difference between a safe method and an idempotent method, and which common verbs fall into each group?
• Why might sending OPTIONS or an unexpected verb like PUT to a route reveal behavior a normal browser session never shows?