302 - Found
HTTP 302 Found means the resource is temporarily at a different URI and clients should follow Location for now.
Last reviewed: February 14, 2026|Editorial standard: source-backed technical guidance
What Does Found Mean?
The resource is temporarily redirected, so clients should follow the current Location without treating it as permanent canonical migration.
Common Causes
- -Authentication middleware redirects unauthenticated sessions to login endpoint as temporary navigation behavior.
- -Traffic experiment framework sends cohort users to alternate path using cookie-based temporary redirect rule.
- -Reverse proxy switches to maintenance landing page during rollout window and issues temporary redirects.
How to Fix Found
- 1Validate temporary redirect targets and ensure they resolve correctly for the active route conditions.
- 2Set cache headers to prevent clients and intermediaries from treating temporary redirects as permanent.
- 3Remove stale or conflicting temporary routing rules that create loops or misdirected traffic.
Step-by-Step Diagnosis for Found
- 1Capture original method/URI plus
Locationand cache headers for every 302 emission. - 2Trace conditions that trigger redirect rules (auth state, feature flag, maintenance toggle, traffic steering).
- 3Inspect client behavior differences for method handling and automatic follow policies.
- 4Retest with redirect handling set to manual and automatic modes to confirm expected outcomes.
Temporary Redirect Rule Trigger Analysis
- -Inspect conditional routing logic (example: unauthenticated session redirected to temporary login bridge endpoint).
- -Validate rule expiry and ownership (example: maintenance redirect remained active after incident closure).
Client and Cache Behavior Validation
- -Check cache directives on 302 responses (example: intermediary caches temporary redirect too aggressively).
- -Compare client redirect semantics (example: some legacy clients alter method on 302 unexpectedly).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 302 Found
# Location: https://api.example.com/v1/temporary-resourceconst response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' },
redirect: 'manual'
});
if (response.status === 302) {
console.error('Handle 302 Found:', response.headers.get('location'));
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'},
allow_redirects=False
)
if response.status_code == 302:
print('Handle 302 Found', response.headers.get('Location'))How to Verify the Fix
- -Confirm 302 appears only for intended temporary scenarios and resolves to the correct destination URI.
- -Validate users and API consumers reach final endpoints without redirect loops or stale redirect caches.
- -Check redirect frequency over time to ensure temporary rules automatically wind down as planned.
How to Prevent Recurrence
- -Attach expiration and owner metadata to temporary redirect rules so they are reviewed and removed on time.
- -Monitor temporary redirect rates per route and alert on unexpected spikes or long-lived growth.
- -Prefer 307 or 308 when strict method preservation is required for write-safe client behavior.
Pro Tip
- -govern temporary redirects as feature flags with enforced TTL so emergency routing rules cannot silently become permanent architecture.
Decision Support
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Compare Guide
404 Not Found vs 410 Gone: Missing vs Permanent Removal
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.
Playbook
Resource State Playbook (404 / 410 / ResourceNotFound)
Use this playbook to separate temporary missing-resource lookups from permanent removals, then fix scope, lifecycle, and identifier drift safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.