📡 ToastRFC

safe method

GET, HEAD, OPTIONS, TRACE

a method whose defined semantics are essentially read-only — the client does not request, and cannot be held responsible for, any change on the server

A request method is safe if its semantics are read-only. GET, HEAD, OPTIONS, and TRACE are safe. This is a promise about intent, not a guarantee the server does nothing (a GET may still write a log line or count a hit) — but a client, crawler, or prefetcher can issue safe requests freely without worrying about side effects it would be blamed for.

Every safe method is also idempotent.

How it is read

RFC 7231 §4.2.1 (2014)

spec

Introduced the modern definition: "Request methods are considered 'safe' if their defined semantics are essentially read-only." Listed GET, HEAD, OPTIONS, TRACE.

RFC 9110 §9.2.1 (2022)

spec

Keeps the definition and the list, and sharpens the guidance for resource authors: "a resource owner ought not distinguish or discriminate" against clients for safe requests, and safe methods are the ones that may be used for prefetching without concern.

In the corpus (1)

HTTP Semantics