Sometimes when you are using an ATG powered website, e.g. Keds, you will see a _requestid parameter in your URL, e.g. http://www.keds.com/?_requestid=138580.
This occurs when the ATG code, typically a form handler, does a local redirect instead of a redirect. This is ATG’s own flavor of redirect which does a few extra things as described in the JavaDoc:
Sends a redirect response to the client using the specified redirect location URL. This function is similar to sendRedirect(), with the following two differences:
- The session ID is added to the URL if a valid cookie with the session ID is not found.
- If the URL is a relative URL (i.e., “login/error.html”), then the URL will be converted to a full absolute URL, as required by the HTTP specification. A relative URL is one that does not specify a protocol (e.g., “http:”).
In general, this function should be used when redirecting back to a page on the same site. If you are redirecting to a page on some other site, use the full absolute URL and call sendRedirect().
However this does not explain the mysterious _requestid parameter. Fortunately ATG’s Programming Guide does:
Preserving Request Scoped Objects on Redirects
If a request results in a redirect to a local page through the method HttpServletResponse.sendLocalRedirect(), the ATG platform treats the redirect request as part of the original request, and maintains any request-scoped objects associated with that request. To implement this, the ATG platform adds an additional query parameter named _requestid to the redirected URL.
Now you know what the _requestid parameter is and why it exists. And if you don’t want it then you the programmer should use a redirect instead of a local redirect.