HTTP 302
The HTTP 302 status code, also known as "Found", is a standard redirection response in the Hypertext Transfer Protocol (HTTP) that indicates the target resource has temporarily relocated to a different uniform resource identifier (URI), with the server providing the new location via the Location header field to guide the client in issuing a follow-up request.[1] This code belongs to the 3xx family of redirection status codes and signals a temporary change, meaning clients should continue using the original URI for future requests rather than treating the relocation as permanent.[2] Defined in the HTTP/1.1 semantics, it allows servers to respond to a request without fulfilling it directly, often including an optional representation of the resource or a hypertext note with a hyperlink to the temporary URI.[1]
In practice, web browsers and user agents typically handle 302 responses by automatically redirecting the client to the URI in the Location header, often converting non-GET methods (such as POST) to GET requests per the Fetch Standard to avoid unintended side effects like resubmitting form data.[3] This behavior makes 302 commonly used for scenarios like temporary maintenance redirects, load balancing across servers, or post-submission confirmations where the original resource might return to its prior location later.[3] However, unlike the 301 (Moved Permanently) code, which implies a lasting change,[4] a 302 does not update search engine indexing permanently and is not intended for long-term redirects; the 301 allows for SEO link equity transfer while 302 does not.[5] Similarly, it differs from 303 (See Other), which explicitly mandates a GET redirect regardless of the original method, making 302 more flexible but potentially leading to method changes in some implementations.[6]
Servers issuing a 302 response must include a valid Location header with an absolute or relative URI, and clients are encouraged—but not required—to follow it, with provisions to detect and avoid infinite redirection loops.[7] The code originated in HTTP/1.0 as "Moved Temporarily"[8] but was renamed "Found" in HTTP/1.1 to better reflect its semantics of discovery rather than movement,[9] and it remains unchanged in modern HTTP specifications.[1] While effective for temporary scenarios, developers are advised to use 307 (Temporary Redirect) for preserving the original request method or 303 for forcing GET in cases involving unsafe methods like POST, to ensure predictable behavior across clients.[3]
Overview
Definition
The HTTP 302 status code, officially designated as "302 Found," indicates that the target resource resides temporarily under a different URI.[10] This response informs the client that the requested resource has been moved to a new location on a short-term basis, and the redirection may change over time.[10]
Semantically, the server instructs the client to issue a subsequent request to the URI provided in the Location header field, reusing the original request method and payload where applicable.[10] However, due to historical ambiguities in earlier HTTP specifications, user agents may change the request method from POST to GET in the redirected request, a behavior that the 302 code does not strictly prohibit.[10]
A key attribute of the 302 Found code is its non-permanent nature; clients ought to continue using the effective request URI for future requests and should not update bookmarks, cached references, or permanent links based on this redirection.[10] This temporary redirection ensures that the original resource location remains the primary reference point until a more stable change is indicated by other status codes.[10]
Purpose
The HTTP 302 Found status code serves as a mechanism for servers to indicate that the requested resource is temporarily available at a different URI, prompting the client to redirect its request accordingly without implying a permanent change. This allows web servers to handle transient situations where the original resource location is unavailable or suboptimal, ensuring that future requests to the original URI continue to be directed there until the temporary condition resolves. The response typically includes a Location header specifying the alternative URI, and the server may provide a brief hypertext note with a link to facilitate user navigation.[10]
In practice, the 302 code is commonly used for temporary resource relocation in scenarios such as site maintenance or load balancing. It supports the code's non-committal nature, avoiding permanent changes in search engine indexing or long-term client-side updates that could occur with permanent redirects like 301.[11]
By enabling seamless navigation to these interim locations, the 302 response enhances user experience in dynamic web environments. User agents typically automatically follow the redirect, preserving the original method where possible, but may change non-idempotent methods like POST to GET.[12] This maintains continuity in resource retrieval while preserving the original request URI for subsequent interactions.
Unlike 4xx client error or 5xx server error codes, the 302 is a redirection status within the 3xx family, signifying a successful initial response that instructs the client to take further action rather than indicating a failure. This classification ensures it does not trigger error handling in applications but instead facilitates proactive resource resolution, with caching possible only if explicitly allowed by accompanying headers like Cache-Control.[10]
History and Specifications
Origins in HTTP/1.0
The HTTP 302 status code, known as "Moved Temporarily," was introduced in the HTTP/1.0 specification outlined in RFC 1945, published in May 1996.[13] This document, authored by Tim Berners-Lee, Roy Fielding, and Henrik Frystyk Nielsen, represented the first formal standardization of HTTP as part of the foundational infrastructure for the World Wide Web, initially developed at CERN to enable distributed information sharing among researchers.[14] The code was defined in Section 9.3 to signal that a requested resource had been temporarily relocated to a new URI, with the server providing the temporary location via the Location header, while advising clients to continue using the original URI for future requests.[15]
In the context of the early 1990s pre-commercial internet, HTTP/1.0 emerged during the web's infancy, when the protocol primarily supported simple, text-based hypermedia navigation over nascent networks like the early ARPANET successors.[16] The 302 code was crafted to handle basic scenarios of resource relocation, such as during site maintenance or experimental server configurations at institutions like CERN, without assuming persistent changes that might disrupt the evolving ecosystem of interconnected documents.[17] This design prioritized minimalism to accommodate limited bandwidth and rudimentary client-server interactions, focusing on temporary redirects to maintain accessibility in a system still dominated by academic and research use cases.
The HTTP/1.0 specification provided directives on handling redirected requests under 302 responses, requiring user agents not to automatically redirect POST requests without user confirmation to avoid changing request conditions, though this led to inherent ambiguity and inconsistent implementations as some early user agents erroneously transformed non-GET methods to GET, potentially altering intended semantics like form submissions.[18][19] Such variations stemmed from the protocol's experimental origins and the absence of robust testing frameworks, highlighting the challenges of standardizing behaviors in a rapidly growing but fragmented web environment.[20]
Evolution in HTTP/1.1 and Later
In the specification for HTTP/1.1, outlined in RFC 2616 published in June 1999, the 302 status code was renamed from "Moved Temporarily" (as used in HTTP/1.0) to "302 Found," with explicit emphasis on its role in indicating temporary resource relocation rather than a permanent change.[21] This update aimed to clarify that the redirection applies only for the current request session, and user agents were required not to automatically redirect non-GET or non-HEAD requests without user confirmation, preserving the original request method.[21]
RFC 7231, published in June 2014 and obsoleting key aspects of RFC 2616, provided further clarifications to the 302 code's semantics while retaining the "Found" designation.[18] It deprecated the prior strict rule against automatic redirection for POST requests by permitting user agents to change the method to GET, reducing interoperability issues with legacy clients, and reinforced that 302 responses denote temporary moves without encouraging caching of the redirect itself unless overridden by explicit headers like Cache-Control.[18] These adjustments addressed ambiguities in earlier implementations, ensuring more consistent handling across diverse HTTP/1.1 environments.
Following the 2014 updates, the 302 status code has seen no substantive changes in subsequent protocol versions, maintaining stability in its core definition. HTTP/2, specified in RFC 7540 (May 2015), preserves all 3xx redirection codes including 302 with identical semantics, leveraging the protocol's binary framing and multiplexing for more efficient transmission of redirect responses without altering their meaning.[22] Likewise, HTTP/3 as defined in RFC 9114 (June 2022) adopts the unchanged 302 semantics from the consolidated HTTP core in RFC 9110, benefiting from QUIC's low-latency transport to streamline redirect processing in modern networks.[23][24]
Syntax and Implementation
Response Structure
The HTTP 302 response follows the standard structure of an HTTP message, consisting of a status line, zero or more header fields, a blank line indicating the end of headers, and an optional message body.[25] The status line begins with the HTTP version (e.g., HTTP/1.1), followed by a space, the numeric status code 302, another space, and a reason phrase such as "Found", terminated by a carriage return and line feed (CRLF, or \r\n).[26] This indicates a temporary redirection, where the target resource resides temporarily under a different URI.[26]
The response requires a Location header field containing a URI reference (absolute or relative) to the temporary location of the resource; relative URIs are resolved relative to the original target URI, and any fragment identifier from the original URI may be inherited if not present in the Location value.[27] No other headers are strictly mandatory for a 302 response, though general HTTP headers like Date or Server may be included for protocol compliance.[25]
If a message body is present, it is typically short and human-readable, such as a hypertext note with a link to the new URI, but including a body is discouraged for redirects to avoid unnecessary data transfer; in such cases, a Content-Type header (e.g., text/html) would specify the body's media type.[26] The body, if included, follows the blank line after the headers and is terminated by the connection close or a Content-Length header.[25]
An example of a minimal 302 response in wire format is:
HTTP/1.1 302 Found\r\n
Date: Sun, 09 Nov 2025 12:00:00 GMT\r\n
Server: ExampleServer/1.0\r\n
Location: https://example.com/temporary-location\r\n
Content-Length: 0\r\n
\r\n
HTTP/1.1 302 Found\r\n
Date: Sun, 09 Nov 2025 12:00:00 GMT\r\n
Server: ExampleServer/1.0\r\n
Location: https://example.com/temporary-location\r\n
Content-Length: 0\r\n
\r\n
This snippet shows the status line, common headers, and an empty body indicated by Content-Length: 0.[26]
The Location header is a required component of an HTTP 302 response, specifying the target URI to which the client should redirect for the temporary relocation of the resource.[18] Per RFC 7231, the server must include this header field containing a URI reference for the alternative URI, and user agents are expected to resolve it according to the rules in RFC 3986.[28]
To manage caching and avoid serving stale redirects, servers often include Cache-Control or Expires headers in 302 responses. The Cache-Control directive "no-cache" instructs caches to store the response but validate it with the origin server before reuse, using mechanisms like conditional requests, while "no-store" prevents storage altogether to ensure freshness for temporary redirects.[29] Similarly, an Expires header can set a specific expiration time, but directives like Cache-Control: max-age=0 effectively render the response immediately stale, prompting revalidation.[30]
Other headers may accompany HTTP 302 responses to handle specific scenarios, such as Retry-After, which indicates the minimum time the client should wait before issuing the redirected request, expressed in seconds or an HTTP-date.[31] The Set-Cookie header can also be included to establish or update cookies for session continuity, allowing the client to send them in the subsequent request to the new URI after the redirect.
For interoperability, the Location header supports relative URI references, which user agents resolve against the effective request URI to form an absolute URI, ensuring consistent redirection even without a full absolute path.[28]
Versus 301 Permanent Redirect
The HTTP 302 Found status code indicates that a resource has temporarily relocated to a different URI, prompting clients to issue a new request to the provided Location header without updating their references to the original URI.[32] In contrast, the HTTP 301 Moved Permanently status code signals a lasting relocation, directing clients to adopt the new URI for all future requests and update any stored references, such as bookmarks.[33] This distinction in permanence ensures that 302 redirects do not alter long-term client behavior, while 301 redirects facilitate a seamless transition to the updated resource location.[34]
Regarding request method handling, both 302 and 301 responses result in user agents typically converting the redirected request to GET regardless of the original method (such as POST), per the Fetch Standard, to avoid unintended side effects.[32][35] This behavior aligns with the specifications' cautions against automatic redirection for unsafe methods without safeguards.[33] Thus, both codes maintain safe, retrieval-oriented follow-ups without implying method preservation, though 301's permanence may influence caching and reference updates more enduringly.
In terms of search engine optimization (SEO), a 302 redirect passes minimal link equity to the target URL, as search engines like Google treat it as temporary and continue prioritizing the original URL in indexing and rankings.[36] Conversely, a 301 redirect fully transfers link equity—often 90-99% of the original's value—to the new URL, enabling it to inherit the SEO authority and appear in search results.[36] This makes 301 ideal for preserving ranking signals during permanent changes, while 302 risks diluting equity if misused for ongoing redirects.[36]
Use cases for 302 diverge from 301 by focusing on short-term scenarios, such as redirecting users to a maintenance page during brief site downtime or A/B testing landing pages without committing to a new structure.[32] In these situations, the temporary signal avoids unnecessary updates to client references or search indices. 301, however, suits long-term URL updates, like domain migrations or content reorganizations, where the new location becomes the definitive endpoint.[33] Misapplying 302 for permanent moves can lead to fragmented SEO signals, underscoring the need for precise selection based on relocation duration.[36]
Versus 303 See Other and 307 Temporary Redirect
The HTTP 302 Found status code, while indicating a temporary redirection similar to 307 Temporary Redirect, differs primarily in its handling of the original request method, leading to historical ambiguities that 303 See Other and 307 were designed to address.[32] Specifically, 302's flexible semantics allow user agents to change non-GET methods, such as POST, to GET during redirection; this has resulted in consistent implementations converting to GET per the Fetch Standard, potentially risking loss of request body data in legacy contexts.[32][35] In contrast, 303 See Other explicitly mandates that the client use the GET method to retrieve the redirected resource, regardless of the original request method, making it particularly suitable for scenarios like form submissions following a POST to prevent accidental resubmission of the form data.[37] This forced method change in 303 ensures a safe, retrieval-oriented follow-up without preserving the original semantics.[37]
The 307 Temporary Redirect, introduced alongside 303 in HTTP/1.1, provides a stricter alternative to 302 by requiring that the original request method and body be preserved in the redirected request, thus avoiding any automatic conversion to GET.[38] Unlike 302's permissive behavior, which could lead to unintended method alterations, 307 ensures the integrity of method-sensitive operations, such as retrying a POST at a temporary alternative URI.[38] Both 303 and 307 were created to resolve the ambiguities inherent in 302's legacy usage, especially in handling form submissions where preserving or altering the method could affect data submission reliability.[39]
In modern HTTP semantics as updated in RFC 9110, 307 is preferred over 302 for temporary redirects in scenarios requiring method preservation, offering clearer intent and reducing compatibility issues with diverse clients.[38] This preference stems from 302's observed inconsistencies in practice, prompting servers to use 303 for GET-forced redirects after POST actions and 307 for method-preserving temporary shifts.[32]
Client Behavior and Implications
Browser Handling
Web browsers and HTTP clients, such as those in Chrome and Firefox, process an HTTP 302 Found response by automatically initiating a new request to the URI specified in the Location header, treating the redirection as temporary.[3] This behavior aligns with the Fetch Standard, which mandates following redirects for status codes including 302 when the redirect mode is set to "follow," the default for most browser-initiated requests.[35] For requests using methods other than GET or HEAD, such as POST, browsers typically convert the method to GET and nullify the request body in the redirected request, a practice rooted in historical HTTP/1.1 semantics to ensure safe idempotency, though this can lead to loss of form data unless a 303 See Other code is used instead.[35]
To prevent infinite redirect loops, browsers impose strict limits on the length of redirect chains, as defined in the Fetch Standard with a default maximum of 20 redirects before terminating the process and returning a network error.[35] In Firefox, this limit is configurable via the network.http.redirection-limit preference, which defaults to 20. Chrome enforces the same maximum of 20 redirects, after which it displays an error like ERR_TOO_MANY_REDIRECTS. Exceeding this threshold triggers a failure state, protecting users from resource exhaustion or denial-of-service scenarios induced by cyclic redirections.[35]
User-facing interactions with 302 redirects are generally seamless and transparent, with the browser navigating to the new location without prompting or interrupting the user experience.[3] However, the redirection process becomes visible in developer tools, such as the Network tab in Chrome DevTools or Firefox's Inspector, where the chain of requests and responses can be inspected for debugging. In cases of failure, such as loop exceedance or invalid Location URIs, browsers may surface an error page or console message to inform the user, though successful redirects remain imperceptible during normal browsing.[3]
Regarding cross-origin scenarios, browsers enforce the same-origin policy on the target resource following a 302 redirect, ensuring that scripts and other features cannot access the redirected content unless it shares the origin with the initiating page.[40] For cross-origin redirects—where the Location URI differs in scheme, host, or port—CORS preflight checks and Access-Control-Allow-Origin headers are required if the request involves credentials or non-simple methods, as the redirection updates the request's URL list and may taint the response as cross-site.[35][41] This mechanism prevents unauthorized data leakage while allowing legitimate navigational redirects across origins in standard hyperlink or form submissions.[40]
HTTP 302 responses are not cacheable by default, as the 302 status code is not listed among cacheable status codes in RFC 9111, to ensure clients always fetch the latest redirect target given the temporary nature of the relocation.[42] Servers can explicitly prevent caching by including the Cache-Control: no-store directive, which instructs clients and intermediaries to avoid storing the response.[43] This behavior aligns with the semantics in RFC 9111, where redirects without freshness indicators like max-age or Expires are considered uncacheable unless explicit directives permit caching, to prevent serving outdated temporary redirects.[44]
Intermediaries such as content delivery networks (CDNs) and proxies may cache 302 responses if explicitly permitted by headers like Cache-Control: public, max-age=3600, but this introduces risks of delivering stale redirects that no longer point to the correct temporary location.[45] For instance, Akamai's property manager allows configurable caching for 302 and 307 redirects to optimize delivery, yet documentation warns that improper TTL settings can lead to prolonged exposure of invalid URIs.[45] Such caching is generally discouraged for temporary redirects unless the backend guarantees short-lived changes, as it can undermine the "found" semantics intended to reflect dynamic resource movement.[42]
The use of HTTP 302 introduces performance overhead primarily through additional round-trip times (RTTs), as clients must issue a follow-up request to the Location header's URI after receiving the redirect.[46] In real-world networks, this typically adds 100-300 milliseconds of latency per redirect, depending on factors like geographical distance and connection quality, with CDN-optimized redirects on the lower end around 10-200 milliseconds.[47] Multiple chained redirects exacerbate this, potentially increasing total load times by hundreds of milliseconds and contributing to higher abandonment rates in user-facing applications.[48]
To mitigate these effects, protocols like HTTP/2 enable multiplexing, allowing parallel streams that reduce head-of-line blocking during redirect chains, though the sequential nature of URI resolution still incurs RTT costs. Client-side techniques such as resource prefetching via <link rel="prefetch"> can anticipate redirects and preload targets, minimizing perceived latency in scenarios like single-page applications. Overall, minimizing 302 usage or combining it with caching directives for stable temporary redirects balances performance without compromising correctness.
Security and Best Practices
Vulnerability Risks
The HTTP 302 Found status code is frequently implicated in open redirect vulnerabilities, where a web application incorporates untrusted user input into the Location header without proper validation, allowing attackers to redirect users to arbitrary malicious sites. This occurs when parameters such as a URL query string are directly used to construct the redirect target, enabling phishing attacks by tricking users into believing they are visiting a legitimate domain. For instance, an attacker might append a malicious URL to a legitimate site's redirect endpoint, such as example.com/redirect?url=phishingsite.com, prompting the server to issue a 302 response that leads the browser to the attacker's controlled page.[49][50][51]
Beyond client-side deception, HTTP 302 redirects can contribute to server-side request forgery (SSRF) risks if the server automatically follows untrusted redirects to internal or restricted resources. In such scenarios, an attacker supplies a redirect URL that points to localhost or internal network endpoints, and poor handling of the 302 response on the server side may result in unintended requests exposing sensitive data like metadata services or administrative panels. This vulnerability has been documented in frameworks where redirect logic fails to sanitize or block follow-on requests, potentially amplifying SSRF impacts in cloud environments.[52]
Historically, HTTP 302 open redirects have been exploited in authentication flows, particularly OAuth implementations and login pages, to facilitate account takeovers or token theft. In OAuth scenarios, attackers manipulate the redirect_uri parameter to an open redirect endpoint, intercepting authorization codes or access tokens during the callback process, as seen in vulnerabilities affecting platforms like Microsoft and GitHub services. The Open Web Application Security Project (OWASP) highlighted unvalidated redirects as a top risk in its 2013 Top 10 list (A10), and while not a standalone category in the 2021 edition, it remains a critical component of broken access control (A01), with ongoing prevalence in phishing campaigns targeting email security filters.[53][54][55][56]
Mitigation Strategies
To mitigate risks associated with HTTP 302 redirects, server-side validation of the Location header URI is essential, involving whitelisting of permitted domains or paths to ensure redirects only point to trusted destinations and prevent unauthorized external routing.[49] This approach uses allow-lists—such as regex patterns matching specific hosts or relative paths—rather than deny-lists, which can be bypassed more easily.[49] For instance, applications can parse and validate the URI scheme, host, and port against a predefined set before issuing the redirect response.[57]
On the client side, modern browsers employ built-in protections like Google's Safe Browsing, which scans and warns users about suspicious redirect chains potentially leading to phishing sites by analyzing URL patterns and reputation data in real-time. Additionally, implementing strict Referrer-Policy headers, such as "strict-origin-when-cross-origin," limits the exposure of sensitive referrer information during redirects, reducing the risk of information leakage across origins.
Among best practices, developers should prefer HTTP 307 Temporary Redirect over 302 when method preservation is required, as 302 may convert POST requests to GET, potentially leading to unintended data loss or exposure, whereas 307 mandates retaining the original method and body. Furthermore, logging all redirect attempts—including the originating request, target URI, user agent, and timestamp—enables anomaly detection through security information and event management (SIEM) systems, allowing identification of unusual patterns like repeated external redirects.[58]
For enhanced protection, integrate web application firewalls (WAFs) such as ModSecurity with the OWASP Core Rule Set (CRS), which includes rules to inspect and block invalid Location headers in real-time; HTTP/3 support was added in 2024 (version 4.0.0), with ongoing updates including improved regex validation in subsequent releases as of 2025. This setup provides layered defense by automatically denying requests attempting open redirects while permitting legitimate internal navigation.[59]
Usage Examples
Basic Redirect Scenario
In a typical web maintenance scenario, a website administrator may need to temporarily redirect traffic from an outdated URL, such as /old-page, to a new one like /new-page, to avoid broken links during a site update without implying permanence to search engines or users.[32] This use of the HTTP 302 status code signals that the redirection is transient, prompting clients to refetch the resource at the new location, typically using the GET method regardless of the original request method.[32]
On the server side, this can be implemented simply in Apache HTTP Server using the mod_alias module within an .htaccess file. The directive Redirect /old-page /new-page issues a 302 response by default, appending the new path to the host's scheme and authority.[60] For more precise control, mod_rewrite allows specifying the status explicitly, as in:
RewriteEngine On
RewriteRule ^/old-page$ /new-page [R=302,L]
RewriteEngine On
RewriteRule ^/old-page$ /new-page [R=302,L]
This rule matches the exact path /old-page and redirects it with a 302 status, stopping further rewriting with the L flag.[61]
Similarly, in Nginx, the ngx_http_rewrite_module handles this via a return directive in the server or location block:
server {
...
location = /old-page {
return 302 $scheme://$host/new-page;
}
}
server {
...
location = /old-page {
return 302 $scheme://$host/new-page;
}
}
Here, return 302 generates the redirect response using the request's scheme and host, ensuring the new URL is fully qualified.[62]
To trace the redirect chain from a client perspective, the curl command with verbose output (-v) and location following (-L) reveals the process. Executing curl -v -L http://example.com/old-page first receives the 302 response:
< HTTP/1.1 302 Found
< Location: http://example.com/new-page
<
* Following redirect to http://example.com/new-page
< HTTP/1.1 302 Found
< Location: http://example.com/new-page
<
* Following redirect to http://example.com/new-page
The client then issues a new GET request to /new-page, fetching its content seamlessly.[63] Without -L, curl would stop after the 302, displaying only the headers.
In a web browser, this 302 redirect results in automatic navigation to /new-page without user intervention or visible prompts, maintaining a smooth user experience while the temporary change is in effect.[32] The response includes a Location header pointing to the new URI, which user agents process to issue the follow-up request.[64]
Advanced Configuration
In RESTful APIs, the HTTP 302 status code is employed for temporary endpoint redirection, such as during API versioning transitions where clients are guided from an older version to a newer one without implying permanence. For instance, a request to /api/v1/users might return a 302 response with a Location header pointing to /api/v2/users, allowing servers to phase out deprecated endpoints while maintaining backward compatibility for a limited period. This approach aligns with the temporary semantics of 302, as defined in RFC 9110, which specifies that the redirection may change and clients should not assume the new URI is enduring.[32][65]
Server-side scripts can dynamically generate the Location header value for 302 responses based on runtime factors like user input, session data, or geolocation. In Node.js with Express, the res.redirect() method defaults to issuing a 302 and supports constructing paths from request parameters; for example, a route handler might compute the target URI using query strings or headers to tailor the redirect, such as routing users to region-specific resources. This enables flexible, context-aware redirections without hardcoding URLs, though the computed URI must conform to URI-reference syntax per RFC 3986 to ensure validity.[66]
Chaining multiple 302 redirects occurs in distributed systems like load-balanced environments, where initial requests are sequentially forwarded across proxies or balancers to reach the appropriate backend, distributing traffic while preserving the temporary nature of each hop. To prevent infinite loops, implementations must alter at least one URI component—such as protocol, host, port, or path—in each Location header, as unchanged redirects can trigger client-side loop detection after a small number of iterations (e.g., 5–10 in common implementations), since clients are required to detect and avoid such loops. AWS Application Load Balancers, for example, enforce this by requiring modifications in redirect rules to avoid cycles during traffic routing.[34]
The Location header in a 302 response accepts URIs with query parameters and fragments, enabling preservation of stateful information like search terms or anchor points during redirection. Query parameters append after the path with a ? delimiter (e.g., Location: /newpage?param=value), while fragments follow with # (e.g., Location: /newpage#section), as permitted by the URI-reference format in RFC 9110, though servers should use absolute URIs to minimize ambiguity and browsers may strip or reattach fragments based on the response context. This handling supports complex scenarios like maintaining form data or client-side navigation states across redirects.[64]