HTTP 301 vs 302: What Testers Need to Know

TL;DR

HTTP 301 means the target resource has moved permanently, while HTTP 302 means it is temporarily available at another URI. Test the first response without following it, validate Location and cache policy, then follow the full chain and verify method behavior, final content, security boundaries, and SEO signals.

Key Takeaways

• 301 communicates a permanent move, while 302 communicates a temporary redirection to another URI.
• Test redirects with automatic following disabled first, otherwise the client can hide the original status and Location header.
• Validate Location resolution, query and fragment handling, allowlisted schemes and hosts, and the final destination separately.
• Browsers and some clients can rewrite POST to GET after 301 or 302, so use and test 307 or 308 when method preservation is required.
• Caching can make an incorrect 301 persist after deployment, so test fresh profiles, intermediaries, and explicit cache policy.
• Redirect chains, loops, mixed protocols, open redirects, and authentication leakage matter as much as the first hop.
• A complete test covers HTTP behavior, browser navigation, canonical and crawl signals, analytics, and rollback readiness.

The http status 301 vs 302 choice tells clients how lasting a redirect is. 301 Moved Permanently says the target resource has a new permanent URI. 302 Found says the client should use another URI for this request, but future requests should continue using the original URI. That distinction affects caches, bookmarks, crawlers, analytics, and rollback behavior.

A green final page is not enough evidence. Many HTTP clients follow redirects automatically and expose only the last 200 response. Testers need to inspect the first hop, Location value, redirect chain, method behavior, cache controls, security boundaries, and destination content. This guide turns those concerns into a systematic redirect test strategy.

TL;DR

The code does not prove the business intent. A test must compare actual behavior with the migration or temporary-routing requirement.

1. HTTP Status 301 vs 302 in Exact Terms

A 301 response tells the user agent that the target resource has been assigned a new permanent URI. Links and future references should use a URI from the Location header. A 302 response says the target is temporarily under a different URI, so a client should continue using the original target for future requests. Both responses direct the current request elsewhere. The durability signal is their primary difference.

The term resource matters. A URL is an identifier for a resource, not merely a file path. A permanent product-page rename, domain migration, or HTTP-to-HTTPS canonicalization can fit 301. A temporary maintenance page, short-lived traffic route, regional incident fallback, or experiment that must preserve the original URL can fit 302. Product intent must be known before a tester can label the code correct.

Neither status means the destination is healthy. Location can be missing, malformed, unsafe, circular, or point to a 404. A correct first status can still create a poor user experience or crawl failure. Conversely, a destination can return 200 while the source uses the wrong permanence signal. Test both layers.

Browsers historically changed some non-GET requests to GET while following 301 and 302. Modern HTTP semantics accommodate that widespread behavior. If the original method and body must be preserved, 307 and 308 express that requirement. This distinction is critical for checkout, form, upload, and API tests. Do not infer method preservation from permanence alone.

2. Compare 301, 302, 303, 307, and 308

Redirect families encode two separate dimensions: permanent versus temporary, and possible method rewrite versus required method preservation. 303 adds an explicit instruction to retrieve another resource with GET or HEAD after processing.

For ordinary GET navigation, 301 and 308 often look similar to a human, as do 302 and 307. For a POST, they can be materially different. A client that changes POST to GET will omit the original request content at the destination. That behavior can prevent resubmission, which is desirable for some web flows, but can silently break an API relocation.

Choose the expected status from the requirement. If a web form processes a POST and then shows a receipt, 303 is an explicit Post-Redirect-Get pattern. If an API moves a POST endpoint temporarily and the destination must receive the same JSON, 307 is the relevant temporary code. If the original GET URL is retired forever, 301 can be suitable.

A test suite should not accept any 3xx indiscriminately. Exact status, Location, method transition, content retention, and cache behavior form the redirect contract.

3. Inspect the First Hop Before Following the Redirect

Automatic following is convenient for application code and dangerous for redirect diagnosis. A client can send /old, receive 301, follow /new, and return only the final 200 to the test. An assertion on 200 then proves that some chain resolved, not that the source issued the expected redirect. Disable automatic redirects for the first test.

Capture exact status and Location. Confirm that Location is present for the redirect branch, contains a valid URI reference, and resolves to the expected destination. Relative references such as /new-path are valid. Resolve them against the source URL with a URI library instead of comparing naive concatenated strings. Define whether query parameters must be preserved, transformed, allowlisted, or removed. Fragments are client-side identifiers and are not sent to the server, but Location can contain one for navigation.

Check response content only when the contract defines it. Redirect bodies can contain a short explanatory page for clients that do not follow automatically, but clients should act on Location. Do not parse a redirect body as the destination representation. Verify media type and accessibility if a user-facing fallback document exists.

Then follow the redirect in a separate assertion. Record each hop, exact status, resolved URL, latency, and final result. Limit the maximum number of hops so a loop fails quickly. A final 200 at an unexpected host or login page is still wrong. Assert the final URL, identity, content, and authenticated state.

This two-phase approach localizes defects: source mapping, Location generation, intermediary chain, or destination behavior.

4. Build Runnable Node.js Redirect Tests

Node.js provides a standards-based global fetch in supported current releases. The redirect: 'manual' option exposes the first redirect to server-side test code. The following script uses the built-in node:test runner, so it needs no assertion library. Set BASE_URL to an approved test host, save the file as redirects.test.mjs, and run node --test redirects.test.mjs.

// redirects.test.mjs
import test from 'node:test';
import assert from 'node:assert/strict';

const baseURL = process.env.BASE_URL ?? 'http://127.0.0.1:8080';
const allowedHosts = new Set(['127.0.0.1', 'localhost', 'web.test.example']);

if (!allowedHosts.has(new URL(baseURL).hostname)) {
  throw new Error('Refusing to test redirects on an unapproved host');
}

test('legacy guide permanently redirects to its canonical URL', async () => {
  const source = new URL('/legacy/api-testing', baseURL);
  const response = await fetch(source, { redirect: 'manual' });

  assert.equal(response.status, 301);
  const location = response.headers.get('location');
  assert.ok(location, 'Expected a Location header');

  const destination = new URL(location, source);
  assert.equal(destination.origin, source.origin);
  assert.equal(destination.pathname, '/guides/api-testing');

  const finalResponse = await fetch(destination, { redirect: 'manual' });
  assert.equal(finalResponse.status, 200);
  assert.match(await finalResponse.text(), /API testing/i);
});

test('maintenance route uses a temporary redirect', async () => {
  const response = await fetch(new URL('/account/reports', baseURL), {
    redirect: 'manual',
    headers: { 'X-Test-Scenario': 'maintenance' },
  });

  assert.equal(response.status, 302);
  assert.equal(response.headers.get('location'), '/maintenance/reports');
});

The APIs shown are public Fetch and Node test APIs. The scenario header is appropriate only when your controlled test environment explicitly supports it. Prefer service configuration or seeded routes over hidden production test switches.

A browser fetch with manual redirect mode can expose an opaque redirect for cross-origin security reasons, so do not assume browser JavaScript can inspect every Location. Use server-side API tests for protocol details and browser automation for real navigation behavior.

5. Test Relative Locations, Queries, Fragments, and Encoding

Location values are URI references. Test absolute URLs, root-relative paths, path-relative references, percent-encoded segments, Unicode domain policy, query strings, and fragments where the application generates them. Use a URL parser to resolve each value. String replacement often mishandles .., duplicate slashes, ports, encoded delimiters, or a base path without a trailing slash.

Define parameter policy with product and security teams. During a route rename, a safe search parameter such as page=2 may need to survive. Tracking parameters might be preserved, dropped, or normalized. Sensitive parameters such as reset tokens must never be copied into an unrelated host or analytics URL. Do not create an open redirect by accepting next=https://attacker.example without an allowlist and canonical validation.

Path encoding can create double-decoding defects. A source like /files/quarter%2Fone should not accidentally become a different path hierarchy after redirect. Test spaces, plus signs, percent signs, non-ASCII text, case sensitivity, and trailing-slash normalization according to the router contract. Confirm one canonical redirect, not alternating slash-add and slash-remove rules.

Fragments deserve browser tests. The fragment is not included in the HTTP request, but the browser uses it after navigation. A migration from /docs#setup to /guide#installation should land on the intended element, not merely the page. Verify focus and scroll behavior without making pixel-perfect assertions that are unstable across viewports.

When Location is generated from request headers behind a proxy, test forwarded-host configuration. The application must not reflect an attacker-controlled Host into an absolute redirect. Prefer trusted proxy configuration and known public origins.

6. Verify Method Rewriting and Request-Body Safety

The most important non-GET test sends a POST to the source and records what reaches the destination. With 301 or 302, many user agents change POST to GET. With 307 or 308, method and request content must be preserved. A framework's internal test client may behave differently from browsers, command-line tools, mobile SDKs, and backend HTTP libraries, so test the supported consumers.

Create a controlled echo destination that records method, selected headers, content type, and a nonsecret payload fingerprint. Never redirect a real payment or destructive call merely to observe behavior. For a browser form flow, assert that the destination receives GET and refreshing the result page does not resubmit. For an API migration, assert a 307 or 308 and that the destination receives the original method and JSON exactly once.

Authorization handling across origins is security-sensitive. A client may remove Authorization on a cross-origin redirect, while cookies follow their domain, path, SameSite, and Secure rules. Tests should not demand credential forwarding to an unrelated origin. Instead, verify that redirect architecture avoids sending secrets across trust boundaries and that the destination has a safe authentication flow.

Payload replay also affects idempotency. A preserved POST can be retried by clients or proxies after a network failure. The destination needs an idempotency contract for high-risk operations. A rewritten GET must not accidentally cause state change. Pair redirect cases with API idempotency testing when orders, bookings, uploads, or payments move between endpoints.

Document client-specific evidence. Saying 302 always converts POST to GET is too absolute. The protocol permits historical behavior, and actual clients differ. Test the clients your product supports and use 307 or 308 when preservation is a requirement.

7. Test Caching, Fresh Profiles, and Rollback

A wrong permanent redirect can remain visible after the server is fixed because browsers, service workers, CDNs, corporate proxies, or search crawlers stored it. Redirect testing therefore needs controlled cache state. Use a fresh browser profile for deterministic first-navigation tests. Clear the relevant CDN or application cache through approved operational mechanisms. Avoid interpreting one warm client as universal behavior.

301 is heuristically cacheable unless cache controls say otherwise. 302 can also be cached when explicit freshness or other caching rules permit. Do not teach that 302 is never cached. Inspect Cache-Control, Expires, Age, and Vary when they participate in the contract. Confirm that personalized or authorization-dependent redirects are not shared across users.

For a permanent migration, test cold request, warm repeat, and source-server unavailability where appropriate. Verify that the cached destination remains correct, but also define an emergency rollback. A long freshness period improves efficiency and can amplify a bad mapping. Release plans should stage rules, monitor them, and avoid irreversible cache durations until confidence is high.

Temporary redirects need expiry evidence. Disable the maintenance or experiment condition and prove the original URL serves its normal response again from a new profile and after intermediary revalidation. Check that no permanent cache, service worker route, or client-side local storage continues redirecting.

Varying by device, language, region, or authentication multiplies risk. Ensure the cache key includes all response-driving dimensions or mark the response private or non-storeable according to architecture. A 302 for one user's onboarding state must never redirect every user through a shared cache.

8. Detect Redirect Loops, Chains, and Performance Waste

A loop can be direct (/a -> /a) or indirect (/a -> /b -> /a). It can also depend on protocol, hostname, slash, locale, cookies, or authentication. Set a low, deliberate maximum hop count in automated checks and report the complete resolved chain on failure. An error such as too many redirects without the chain wastes investigation time.

Redirect chains often accumulate during migrations: HTTP -> HTTPS -> www -> new path -> locale -> final page. Each hop adds network work, increases failure surface, and may lose parameters or analytics attribution. Define a budget, commonly zero or one redirect for important canonical navigation, based on your product requirements rather than an invented universal threshold. Test from representative old links and variants.

A small chain collector makes the behavior visible:

async function collectRedirects(startURL, maxHops = 6) {
  const hops = [];
  let current = new URL(startURL);

  for (let index = 0; index < maxHops; index += 1) {
    const response = await fetch(current, { redirect: 'manual' });
    hops.push({ url: current.toString(), status: response.status });

    if (response.status < 300 || response.status >= 400) {
      return { hops, finalResponse: response };
    }

    const location = response.headers.get('location');
    assert.ok(location, `Redirect at ${current} has no Location`);
    current = new URL(location, current);
  }

  throw new Error(`Exceeded ${maxHops} redirects: ${JSON.stringify(hops)}`);
}

Add a visited-URL set if you want immediate cycle identification. Keep fragments out of server request identity when modeling loops because they are not transmitted. Record timings separately rather than asserting tight public-network milliseconds in CI. Performance budgets should run in a controlled environment.

9. Cover Open Redirects, HTTPS Downgrades, and Data Leakage

An open redirect accepts attacker-controlled input and sends users to an arbitrary destination under the trusted site's response. Attackers use this behavior in phishing and authorization-flow abuse. Test parameters such as next, returnTo, redirect_uri, and encoded variants. The server should use exact registered URLs or a strict allowlist, normalize before validation, and reject scheme-relative, credential-containing, mixed-case, double-encoded, or backslash-confused bypasses.

Do not send Location from HTTPS to HTTP except for a narrowly justified environment. A downgrade can expose subsequent requests to network observation or manipulation. Verify the scheme at every hop, HSTS behavior for supported domains, secure cookies, and no sensitive query propagation. A redirect to another HTTPS host is still a trust-boundary change.

OAuth redirect URIs require exact protocol-specific testing. Do not generalize a site's loose return-path logic to authorization callbacks. Verify registered client, exact redirect URI matching as specified by the identity system, state correlation, PKCE where applicable, and rejection before credentials or codes are sent to an invalid target.

Headers and logs can leak too. Referer behavior depends on Referrer-Policy, origin relationships, and downgrade rules. Test that sensitive paths and queries are not disclosed to the destination or third-party resources. Ensure analytics events use sanitized URLs and distinguish source from destination without duplicating conversions.

For a wider negative-testing method, see API security testing basics. Redirect security cases should be authorized, bounded, and executed on test systems. Do not use real tokens or external attacker-controlled domains in shared automated environments.

10. Validate SEO, Canonical, Sitemap, and Crawl Behavior

For public pages, HTTP status is one signal in a larger canonicalization system. A permanent migration should align redirect destination, HTML canonical link, internal links, sitemap entries, hreflang annotations, structured data URLs, and navigation. Conflicting signals, such as 301 to URL B while B declares A canonical, create a loop in meaning even if browsers render successfully.

A temporary 302 should preserve the original URL as the intended stable entry. Confirm the temporary destination does not replace the source throughout internal navigation and sitemaps unless the product has deliberately changed. When the temporary condition ends, remove the redirect and retest the original page from a clean cache.

Test all meaningful source variants: uppercase policy, trailing slash, legacy extension, encoded path, query parameters, mobile or old subdomain, and HTTP. Map each to one canonical HTTPS destination. Avoid blanket rules that send every unknown path to the home page with 301. A retired page with no meaningful replacement may need 404 or 410. Redirecting unrelated content can confuse users and crawlers.

Crawl a staging URL map with an allowlisted tool, but remember that staging authentication and noindex can change results. In production smoke checks, keep request volume safe and use a curated critical set. Validate source status without following, final status with following, hop count, canonical, robots directives, and sitemap membership.

For launch-facing checks, connect this matrix to the repository's existing smoke suite and keep fixtures deterministic. SEO validation is not only marketing QA. It is contract testing for public URL identity and migration behavior.

11. Design the HTTP Status 301 vs 302 Test Matrix

Build rows by intent and client, not just old URL and new URL. A practical matrix includes:

1. Permanent GET migration -> 301, exact canonical Location, final 200.
2. Temporary GET route -> 302, temporary Location, source restored after condition.
3. Permanent API method-preserving move -> 308, destination receives method and content.
4. Temporary API move -> 307, preserved method and content.
5. Form Post-Redirect-Get -> documented 303 or established 302 behavior in supported browsers.
6. Query allowlist -> safe values preserved, sensitive or unknown values handled by policy.
7. Relative Location -> correctly resolved by real clients.
8. Loop and chain variants -> bounded hop count and useful diagnostics.
9. Cross-origin target -> authorization and cookies not leaked.
10. Malicious destination input -> rejected or normalized into an approved local target.
11. Warm cache -> correct reuse without cross-user routing.
12. Rollback -> original URL works from fresh and revalidated clients.
13. SEO alignment -> final canonical, links, sitemap, and crawl directives agree.
14. Analytics -> one intended page view or conversion with accurate attribution.

Run protocol checks with redirects disabled, then browser navigation with redirects enabled. Use mobile or backend SDK tests where they have distinct redirect implementations. Keep destinations inside approved test hosts and expose the chain in failure reports.

For a broader HTTP response strategy, API error handling and negative testing helps connect redirect branches with authentication, validation, rate limits, and dependency failures.

12. Test Real Browser Navigation and Accessibility

Browsers incorporate history, address bar state, cookies, service workers, CSP, downloads, mixed content, and focus. A server-side HTTP test cannot prove those outcomes. Use a fresh Playwright context to navigate from the source, then assert final URL and visible content. Capture the first navigation response when possible so a final 200 does not hide the source code.

import { test, expect } from '@playwright/test';

test('legacy documentation reaches the canonical page', async ({ browser }) => {
  const context = await browser.newContext();
  const page = await context.newPage();

  const response = await page.goto(`${process.env.BASE_URL}/legacy/api-testing`);
  expect(response?.status()).toBe(200);
  await expect(page).toHaveURL(//guides/api-testing$/);
  await expect(page.getByRole('heading', { level: 1 })).toContainText('API Testing');

  await context.close();
});

page.goto returns the main-resource response for the final navigation after redirects, so retain the manual HTTP test for first-hop status. The browser test proves the user's actual landing behavior. Add route or server logging in a controlled environment if you need every hop.

For accessibility, check that a fragment target receives sensible focus when the application promises it, the final page has one clear heading, and an unexpected maintenance redirect communicates status without trapping keyboard users. Avoid client-side redirect code that flashes inaccessible content or breaks the Back button. Test Back and Forward behavior for login, checkout, and consent flows because redirect history affects task completion.

Interview Questions and Answers

Q: What is the main difference between 301 and 302?

301 communicates that a resource has moved permanently, so clients should prefer the new URI in future. 302 communicates a temporary alternate location, so future requests should keep using the original URI. I verify the business intent, not just the destination.

Q: How do you test a redirect response?

I disable automatic following, assert the exact status and Location, resolve the URI safely, and inspect cache and security headers. Then I follow the chain separately and verify hop count, final URL, content, authentication, and user experience.

Q: Do 301 and 302 preserve POST?

Clients can rewrite POST to GET for historical 301 and 302 behavior. If method and content preservation are required, use and test 307 for temporary or 308 for permanent redirection. I verify supported clients against an echo endpoint.

Q: Is 302 never cached?

No. A 302 can be cached when caching rules and response metadata permit it. I inspect explicit freshness, Vary, user specificity, and intermediary behavior rather than relying on that myth.

Q: What is an open redirect?

It is a redirect endpoint that lets untrusted input choose an arbitrary destination. I test encoding and parsing bypasses, enforce normalized allowlisted targets, and confirm credentials, codes, and sensitive query values never go to an untrusted origin.

Q: Why can a final 200 assertion be misleading?

Automatic following can hide whether the source returned 301, 302, a long chain, or even an unintended login redirect. The final page can be healthy while permanence, caching, method behavior, or source mapping is wrong. First-hop and end-to-end checks solve different problems.

Q: How do you test a permanent redirect rollout safely?

I validate a curated map in staging, begin with conservative cache freshness, use fresh and warm clients, monitor chains and destination errors, and keep a rollback plan. Then I verify canonical, sitemap, internal-link, and analytics alignment.

Q: When would you use 303 instead of 302?

303 explicitly directs the client to retrieve another resource with GET or HEAD, commonly after processing a POST. It makes Post-Redirect-Get intent clearer. I test that refresh does not resubmit the original mutation.

Common Mistakes

• Allowing the HTTP client to auto-follow and asserting only the final 200.
• Choosing 301 for a temporary campaign, incident route, or experiment that needs quick rollback.
• Assuming 302 is never cached or 301 is permanently irreversible in every client.
• Expecting 301 or 302 to preserve POST method and request content across all clients.
• Comparing Location as a raw string without URI resolution and encoding tests.
• Ignoring loops, multi-hop chains, trailing-slash conflicts, and HTTP-to-HTTPS variants.
• Forwarding Authorization, reset tokens, or sensitive query data across origins.
• Implementing an open redirect through weak prefix or substring allowlists.
• Redirecting every missing page to the home page instead of preserving resource meaning.
• Testing protocol behavior but skipping browser history, focus, service worker, analytics, and SEO signals.

Conclusion

The http status 301 vs 302 decision expresses permanence. A 301 says clients should adopt the new URI, while a 302 says the alternate is temporary and the original remains the future entry point. That signal becomes trustworthy only when Location, method behavior, caching, chain resolution, security, and destination content agree.

Start by disabling automatic redirects for one critical URL migration. Assert the exact first response, resolve and validate Location, capture every hop, and then repeat in a fresh browser profile. Add a rollback test before increasing cache duration. Redirects are small responses with unusually long consequences.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• HTTP 200 vs 201: What Testers Need to Know
• HTTP 400 vs 422: What Testers Need to Know
• HTTP 401 vs 403: What Testers Need to Know
• HTTP 404 vs 410: What Testers Need to Know
• HTTP 500 vs 503: What Testers Need to Know
• HTTP 204 no content: What Testers Need to Know