HTTP Methods

Introduction

HTTP methods in HTML form markup (GET vs POST, formmethod override, fetch from buttons) determine how user input hits servers — idempotent bookmarkable searches vs mutating submissions with CSRF tokens. Staff engineers align method, action URL, enctype, and SameSite cookies in HTML forms with API idempotency rules.

Business problem

Business pressure: POST used for search — breaks back button and creates duplicate URL index; GET used for password change — credentials in logs and Referer leakage; missing method defaults GET surprises on destructive actions.

• Security: State-changing GET enables CSRF via img tag; POST needs token
• SEO: GET parameters indexed — choose method intentionally for filters.
• API: HTML forms only natively support GET/POST — method tunneling for PUT/DELETE needs fetch or _method field convention.

Why this feature exists

Platform motivation: HTML forms are the original hypermedia controls for HTTP — method attribute maps to request verb.

• History: GET safe/idempotent; POST process in early HTTP; HTML5 formmethod on buttons
• Alternative rejected: All POST everything — loses cacheable search URLs.
• Modern role: Progressive enhancement fetch submit with method from form for SPA hybrids.

Browser internals

Form submission: Build request from method, action, enctype; navigate top-level or target attribute; download attribute special case.

• Parser: method attribute case-insensitive get/post; invalid values default GET
• DOM: requestSubmit() vs submit() triggers constraint validation
• Script impact: preventDefault on submit + fetch with method from form dataset pattern

Rendering workflow

Navigation: GET form causes full document navigation — new HTML load; POST PRG pattern returns redirect HTML response.

• Critical path: Full page reload form vs fetch API partial update — HTML method choice drives UX
• Layout: N/A method specific
• Paint: Flash of new document on GET search submit

Feature deep dive

Form method reference: method=get for searches filters — query string; method=post for mutations login payment; enctype application/x-www-form-urlencoded default; multipart/form-data for file input; formmethod on button for dual-action forms rare.

• GET limits: URL length ~2k practical; no body; cached
• POST: Body encoding; not idempotent; CSRF token hidden input
• REST HTML gap: DELETE via form needs method=post + _method=DELETE server convention — document clearly.

<!-- Search: GET bookmarkable -->
<form action="/search" method="get">
  <label for="q">Search</label>
  <input id="q" name="q" type="search">
  <button type="submit">Search</button>
</form>

<!-- Login: POST + CSRF -->
<form action="/login" method="post">
  <input type="hidden" name="csrf" value="token">
  <label for="user">User</label><input id="user" name="user" autocomplete="username">
  <label for="pass">Password</label><input id="pass" name="password" type="password" autocomplete="current-password">
  <button type="submit">Sign in</button>
</form>

Accessibility analysis

Form a11y + method: Submit button type=submit explicit; destructive POST confirm pattern accessible dialog; GET errors surfaced in page with aria-live summary.

• Screen readers: Announce validation errors on POST fail return
• Keyboard: Enter in single input submits form — know method implications
• WCAG: Error identification 3.3.1 on server response HTML

SEO impact

GET SEO: Faceted navigation GET creates many indexable URLs — canonical and robots meta on filter combinations; POST results not linkable — correct for account settings.

• Crawl: Google follows GET forms with submit input in simple cases — rare now
• Rich results: N/A method
• Core Web Vitals: Full navigation POST-redirect-GET vs SPA fetch INP trade-off

Security considerations

Method security: Never sensitive data in GET; CSRF on POST; SameSite cookies; action attribute absolute path prevent open form action injection in CMS.

• XSS: Steal CSRF token via XSS still defeats — fix XSS first
• CSRF: POST + token + SameSite=Strict/Lax appropriate
• Open redirect: action attribute validate server-side

Performance impact

Perf: GET cacheable at CDN for public search — careful personalization; POST HTML full round trip — consider fetch for INP on hybrid pages.

• LCP: Full page reload after POST slower than client route — hybrid pattern
• INP: fetch submit avoids document unload jank
• CLS: PRG redirect HTML stable layout template

Real production example

PRG pattern: POST payment → 303 See Other → GET receipt HTML — prevents duplicate charge on refresh.

Enterprise usage

Enterprise: Form method lint in templates — search GET, mutations POST; API gateway rejects GET with body from misconfigured clients mirroring HTML rules.

• Design system: Form component sets method prop with docs
• CMS: Search module method=get enforced
• CI gates: Security scanner flags password fields in GET forms

Common production failures

What breaks in prod: Logout as GET link — CSRF logged users out via img tag embedded in forum post.

• Incident: Payment POST without PRG — duplicate charges on refresh F5
• SEO regression: Session IDs in GET URLs indexed — method misuse
• Perf regression: N/A direct

Architecture review questions

• Is GET used only for safe idempotent reads?
• Do POST forms include CSRF protection?
• Is PRG used after successful mutations?
• Are password and tokens never in GET URLs?
• Does action attribute point to validated same-origin path?

Hands-on project

Project: Implement search GET form and login POST form with CSRF hidden field; document PRG for mock mutation.

• Deliverable: two forms semantically correct
• Verify: GET appears in URL bar; POST does not leak in Referer to third party
• Stretch: fetch submit preserving method for SPA demo

Interview questions

Try it yourself

Edit the HTML, CSS, or JS panels — the preview updates as you type.

Summary

HTTP methods reference ties HTML form method/action/enctype to GET idempotent searches vs POST mutations, CSRF defenses, PRG pattern, and faceted navigation SEO implications.