HTTP Method Tester

How does a server say which HTTP methods a URL supports?

By answering each method: RFC 9110 requires a 405 Method Not Allowed to carry an Allow header listing the supported methods, 501 means the server does not implement the method at all, and an OPTIONS request may be answered with Allow too. Every general-purpose server must support GET and HEAD; PUT, PATCH and DELETE should be refused, or demand authentication, wherever they are not meant to be used.

Security note: Test write methods only against systems you are authorised to test: an endpoint that accepts an anonymous DELETE may really delete something.

How to use HTTP Method Tester

1. Enter the URL of the resource, for example https://api.example.com/v1/items.
2. Tick the methods to test. GET, HEAD and OPTIONS are on by default; tick POST, PUT, PATCH or DELETE only for a URL you own or are allowed to test.
3. Press Send the methods and read Answers by method: the status and what it means for each method.
4. Read Findings for anything that disagrees with RFC 9110, and Allow and CORS headers for what the server advertises.

HTTP Method Tester features

• Sends any of GET, HEAD, OPTIONS, POST, PUT, PATCH and DELETE to one URL, once each, and shows every status code side by side
• Explains each answer in plain words: successful answer, redirect (not followed), needs authentication, forbidden, method not allowed, not implemented, server error, no answer
• Shows the Allow header and the Access-Control-Allow-Origin, -Methods and -Headers values the answers carried
• Flags what disagrees with RFC 9110: a 405 without an Allow header, HEAD refused while GET works, an Allow header that contradicts the answers
• Calls out write methods that answer 2xx to an anonymous, empty request, so you can check whether they should demand authentication
• Write methods are off by default, and nothing of yours but the method and the URL is ever sent

Inputs and outputs

Inputs

• URL to test — an http:// or https:// URL with a public host name; "example.com/path" gets https://. User names and passwords in the URL are refused.
• Methods — GET, HEAD and OPTIONS on by default; POST, PUT, PATCH and DELETE off until you tick them. Nothing else can be chosen.

Outputs

• Summary — how many methods were sent, answered 2xx, were refused or not allowed, and got no answer.
• Answers by method — the status code and reason, what it means, the Allow header, the Content-Type and the time to answer, per method.
• Findings and Allow and CORS headers — what disagrees with RFC 9110, write methods that answered 2xx, and the advertised Allow and CORS values.
• About this test — exactly what was sent, so the result is read for what it is.

HTTP Method Tester example

https://api.example.com/v1/items with GET, HEAD, OPTIONS, POST and DELETE ticked

Summary: Methods sent 5 · Answered 2xx 2 · Refused or not allowed 3 · No answer 0
Answers by method: GET 200 OK — Successful answer · HEAD 405 Method Not Allowed — Method not allowed (Allow: GET, POST, OPTIONS) · OPTIONS 204 No Content — Successful answer · POST 401 Unauthorized — Needs authentication · DELETE 405 Method Not Allowed — Method not allowed
Findings: HEAD is refused while GET works; RFC 9110 expects every general-purpose server to support HEAD wherever it supports GET. · No CORS headers were returned. The probes send no Origin header…
Allow and CORS headers: Allow header GET, POST, OPTIONS · Access-Control-Allow-Origin Not sent

How to read the HTTP Method Tester results

2xx means the server answered the method for this URL. For POST, PUT, PATCH or DELETE it does not mean anything was created or deleted — the request had no body and no credentials — only that the server did not refuse it.

405 or 501 means the method is not available on this URL; 401 or 403 means it may exist but needs authentication or permission. For an API, refusing unknown methods with 405 and an Allow header is the expected behaviour.

A 3xx is reported and not followed: the method may behave differently at the URL the redirect points to, so test that URL as well.

"No answer" means the probe got no response within 8 seconds, the connection failed, or the name did not resolve; a firewall that silently drops some methods looks the same.

When to use HTTP Method Tester

• Checking that an API refuses the methods it does not implement, with 405 and a correct Allow header.
• A security test: confirming that DELETE, PUT or PATCH on a resource are not accepted without authentication.
• Debugging a "405 Method Not Allowed" from a client by seeing what the server really accepts at that URL.
• Verifying that HEAD works where GET does, for monitoring and caching tools that rely on it.

Troubleshooting

• Every method shows "No answer in time": the host is slow or drops connections from cloud networks. Try again, or test from your own computer with curl.
• The page refuses the URL as not public: private, local and reserved addresses, and this site's own addresses, are never contacted.
• "You have reached the request limit": each method counts as one outbound request against a per-minute allowance. Test fewer methods, wait a minute, or sign in for a larger allowance.
• Every method answers 403 or the same page: a firewall or bot protection in front of the site answers instead of the application; the results then describe that layer, not the API.

Frequently asked questions about HTTP Method Tester

Technical notes

RFC 9110 §9 defines the methods: GET and HEAD are safe, PUT and DELETE idempotent, POST neither, and every general-purpose server must support GET and HEAD. A 405 Method Not Allowed answer must carry an Allow header listing the methods the resource supports (§15.5.6, §10.2.1), and 501 Not Implemented means the server does not recognise the method at all. PATCH is defined by RFC 5789.

Each probe is one request made by the Mutqan server through its diagnostic relay: the host is resolved through DNS-over-HTTPS and refused unless every address is public, the request carries only the method, the URL, a fixed User-Agent and the relay's X-Mutqan-Relay: 1 header, and the answer's body is not read. TRACE (which echoes the request back) and CONNECT (which opens a tunnel) are not in the set and are never sent.

CORS headers (Access-Control-Allow-Origin, -Methods, -Headers) are reported as the answers carried them. The probes send no Origin header, so a server that varies its CORS answer by origin may send none here; a real browser preflight is an OPTIONS with Origin and Access-Control-Request-Method, which the CORS Tester sends.

Limitations and methodology

It is not a request proxy: no body, cookies, tokens or custom headers can be sent, so an endpoint that requires them answers only with its refusal.

The URL is sent as you enter it, path and query string included, and POST, PUT, PATCH and DELETE can act on a real resource even without a body: test only URLs you own or are allowed to test.

Only the seven methods listed exist here; TRACE, CONNECT and custom methods (PROPFIND, PURGE) are never sent.

The requests come from the Mutqan server's network, not from your computer; servers that treat cloud traffic, regions or bots differently may answer you differently.

One request per method is a snapshot: rate limits, load balancers with different backends and caches can change the answer on the next request.

Security and privacy

The URL is sent to the Mutqan server, which sends the chosen methods to that host from its own network; nothing you type except the URL reaches the host, and nothing is stored.

References

• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• Allow header — MDNMDN Web Docs (Mozilla)The Allow response header: the methods a resource supports, and why a 405 answer must send it.
• OPTIONS request method — MDNMDN Web Docs (Mozilla)OPTIONS: asking a server which methods a URL allows, and its role as the CORS preflight.