12 KiB
| title | chunk | source | category | tags | date_saved | instance |
|---|---|---|---|---|---|---|
| Safe (HTTP Methods) - Glossary | MDN | 1/3 | https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP | reference | web, html, css, javascript, documentation | 2026-05-05T05:44:23.877080+00:00 | kb-cron |
MDN HTML HTML: Markup language
HTML reference
HTML guides
Markup languages
CSS reference
CSS guides
Layout cookbook
JavaScriptJS JavaScript: Scripting language
JS reference
JS guides
Web APIs Web APIs: Programming interfaces
Web API reference
Web API guides
- Using the Web animation API
- Using the Fetch API
- Working with the History API
- Using the Web speech API
- Using web workers
Technologies
Topics
Learn Learn web development
Frontend developer course
- Getting started modules
- Core modules
- MDN Curriculum
- Check out the video course from Scrimba, our partner
Learn HTML
Learn CSS
Learn JavaScript
Tools Discover our tools
About Get to know MDN better
Safe (HTTP Methods)
An HTTP method is safe if it doesn't alter the state of the server. In other words, a method is safe if it leads to a read-only operation. Several common HTTP methods are safe: GET, HEAD, or OPTIONS. All safe methods are also idempotent, but not all idempotent methods are safe. For example, PUT and DELETE are both idempotent but unsafe.
Even if safe methods have a read-only semantic, servers can alter their state: e.g., they can log or keep statistics. What is important here is that by calling a safe method, the client doesn't request any server change itself, and therefore won't create an unnecessary load or burden for the server. Browsers can call safe methods without fearing to cause any harm to the server; this allows them to perform activities like pre-fetching without risk. Web crawlers also rely on calling safe methods.
Safe methods don't need to serve static files only; a server can generate an answer to a safe method on-the-fly, as long as the generating script guarantees safety: it should not trigger external effects, like triggering an order in an e-commerce website.
It is the responsibility of the application on the server to implement the safe semantic correctly, the web server itself, being Apache, Nginx or IIS, can't enforce it by itself. In particular, an application should not allow GET requests to alter its state.
A call to a safe method, not changing the state of the server:
A call to a non-safe method, that may change the state of the server:
A call to an idempotent but non-safe method: