📜 Reading: RFC Specifications

When the server knows the condition is likely permanent:

The RFC states: "the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent."

Key distinction:

• 404 Not Found → resource doesn't exist right now, or server won't say. It does NOT tell the client whether the absence is temporary or permanent.
• 410 Gone → server explicitly communicates: "this was here, it's permanently gone, stop asking"

Why this matters for SEO and crawlers:
Search engine crawlers treat 410 differently from 404. A 410 tells Google to immediately deindex the URL, while 404 may be retried.

RFC language: SHOULD vs. MUST:
This RFC uses "SHOULD" (not "MUST") for preferring 410 over 404. This means it's recommended but not required — there are valid reasons to use 404 for a permanently missing resource (e.g., you simply don't know if it's permanent).

Reading RFCs: The language is extremely precise. Every word like "indicates", "preferred", "SHOULD", "MUST" has a specific technical meaning defined by RFC 2119.

Cache-Control headers can override the default:

The phrase "unless otherwise indicated by… explicit cache controls" means the caching default (cacheable) can be overridden. In HTTP, this is done via the Cache-Control response header.

Practical examples:

Cache-Control: no-store        → don't cache this 404 at all
Cache-Control: max-age=60      → cache it for 60 seconds
Cache-Control: no-cache        → cache but revalidate before using

Why "cacheable by default" for 404s matters:
If your server returns 404 for a resource that temporarily doesn't exist (e.g., during a deploy), caches might hold that 404 for a while. You'd want to add Cache-Control: no-store to prevent stale 404 pages from being served.

RFC reading technique — "i.e." vs "e.g.":

• i.e. (id est) → "that is" — a restatement, clarification
• e.g. (exempli gratia) → "for example" — one instance among many

The RFC uses "i.e." in "A 404 response is cacheable by default; i.e., unless otherwise indicated…" — this is a clarification of what "by default" means, not a new rule.

SHOULD = recommended but not mandatory:

RFC 2119 is clear: "SHOULD… means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

So "SHOULD send X-Request-ID" means:

• ✅ You should send it — it's the recommended practice
• ⚠️ You can omit it, but you should know what you're giving up (e.g., request tracing in logs, debugging support)
• ❌ The server won't reject your request — but features that depend on the header won't work

The RFC 2119 hierarchy (memorize this for reading any standard):

• MUST / REQUIRED / SHALL → absolute requirement
• MUST NOT / SHALL NOT → absolute prohibition
• SHOULD / RECOMMENDED → strongly advised, deviations allowed with justification
• SHOULD NOT / NOT RECOMMENDED → generally avoid, deviations allowed with justification
• MAY / OPTIONAL → truly optional, no preference implied

Key insight: When reviewing your team's API or protocol documentation, checking whether a requirement uses MUST vs. SHOULD tells you whether violating it is a bug or an acceptable trade-off.