Engrain by ByteRush

WEB.12.01 Mid-level· 12 minCore — asked often

HTTP semantics in depth: methods, status codes and negotiation

Which HTTP methods are safe and idempotent and why it matters, the status codes interviewers ask about (301/302/307/308, 401 vs 403, 409, 412, 422, 429), content negotiation, and compression with gzip, Brotli and zstd.

Comes up in: Web fundamentals, Recruiter screen, Backend design

Learn#

Mohit’s payment form sometimes charges customers twice. When a mobile connection drops, his client code retries every failed request, including the POST that creates the charge.

HTTP methods have defined meanings in RFC 9110. A safe method (GET, HEAD, OPTIONS, TRACE) only reads; it must not change anything on the server. An idempotent method gives the same server state whether you send it once or many times: all safe methods, plus PUT and DELETE. POST and PATCH are neither, so a blind retry can repeat their effect.

Status codes tell the client what to do next:

CodeMeaningClient should
301 / 308Moved permanentlyUpdate links; 308 keeps the method and body
302 / 307Moved temporarilyFollow once; 307 keeps the method and body
401Not authenticatedLog in, then retry
403Authenticated, not allowedNot retry; show “no access”
409Conflict with current stateRefresh and resolve
412A precondition (If-Match) failedReload; someone else changed it
422Valid syntax, invalid contentShow field errors
429Too many requestsWait (Retry-After), then retry
Why retrying POST is riskyStep 1 of 4

Network

  • POST /orders … ✗ connection reset

State

    empty

    The browser sends POST /orders. The network drops before the response arrives. Did the order go through?

    Read the steps as text
    1. The browser sends POST /orders. The network drops before the response arrives. Did the order go through?
    2. POST is not idempotent: sending it again might create a second order, so browsers and proxies never retry it on their own.
    3. PUT /orders/123 with the full order is idempotent: sending it twice leaves the same result as once.
    4. So the client can retry PUT and DELETE safely, but POST needs an idempotency key (WEB.15.01).

    Predict#

    Predict first

    A form POSTs to /login, and the server replies 302 to /dashboard. What does the browser send next?

    Interview angle#

    Say it like this — about 30 seconds

    “Safe methods only read: GET, HEAD and OPTIONS. Idempotent methods leave the same state no matter how many times you send them: the safe ones plus PUT and DELETE. That matters for retries, because only idempotent requests can be retried blindly; POST needs an idempotency key. For redirects, 301 and 302 may change POST to GET, while 307 and 308 keep the method. 401 means not authenticated; 403 means authenticated but not allowed.”

    Stays on your device. Nothing is uploaded.
    Follow-up Which HTTP methods are idempotent, and why does it matter?
    GET, HEAD, OPTIONS, TRACE, PUT and DELETE. Clients and proxies can safely retry them after a network failure.
    Follow-up 301 vs 302 vs 307 vs 308?
    301 and 308 are permanent, 302 and 307 temporary. 307 and 308 must keep the method and body; 301 and 302 may become GET.
    Follow-up 401 vs 403?
    401: who are you? Send credentials. 403: I know who you are, and the answer is no.

    Practice#

    Guided

    Encode the method properties, the redirect choice and the 401/403 rule.

    Done when

    • Safe: GET, HEAD, OPTIONS, TRACE. Idempotent: those plus PUT and DELETE.
    • The four redirects map to 301, 302, 307 and 308 correctly.
    • authStatus returns 401, 403 or 200.
    Your solution
    Ctrl/⌘ + Enter

    Remember#

    Try to answer each card before you open it. Then add them to your reviews.

    Which methods are idempotent?

    GET, HEAD, OPTIONS, TRACE, PUT and DELETE.

    Which redirect keeps the method and is permanent?

    308.

    401 vs 403?

    401: not authenticated. 403: authenticated but not allowed.

    What does 429 mean, and which header helps?

    Too many requests; Retry-After says when to try again.

    Go deeper

    Four layers. Stop at the one your interview needs; each ends with a quick check.

    The core ideaEvery round

    Idempotency is about the effect on the server, not the response: a second DELETE may return 404, but the state is the same Source: RFC 9110: Idempotent methods.

    Check yourself: Is DELETE idempotent even if the second call returns 404?

    Yes. Idempotency is about server state, not the response code.

    How it works underneathSenior rounds
    Content negotiation lets one URL serve different forms: the client sends Accept, Accept-Language and Accept-Encoding, and the server picks, adding Vary so caches keep the versions apart (WEB.13.01).
    Check yourself: Which request header lists the formats a client accepts?

    Accept (and Accept-Encoding, Accept-Language).

    Edge cases and trapsWhere people slip

    409 says the request conflicts with the current state, such as a duplicate username. 412 says a condition the client sent failed, such as If-Match with an old ETag: the safe way to stop lost updates.

    Check yourself: What is the difference between 409 and 412?

    409: the request conflicts with current state. 412: a conditional header such as If-Match failed.

    In productionStaff-level answers
    Compression shrinks text: gzip everywhere, Brotli smaller (precompress static files at a high level), and zstd, fast for dynamic responses: Chrome 123, Firefox 126, Safari 26.3. Images and video are already compressed Source: MDN: Compression in HTTP.
    Check yourself: Which compression is usually best for static text files?

    Brotli at a high level, precompressed at build time.

    Finished the five steps? Mark it, and its cards join your reviews.

    Last checked 2026-11-01. Spot a mistake? Use “Report an error” below — fixes are listed on the corrections page.

    Interview questions this answers

    • Which HTTP methods are idempotent? Why does it matter?
    • 301 vs 302 vs 307 vs 308?
    • 401 vs 403?