I want this page to return 200 whilst still sending the redirect...
<script>
sub page_load
'Get the parameters
dim content As String
content = request.querystring("text")
response.redirect ("http://100.200.100.10/test1/Default.aspx?CommandParm=" + content)
end sub
</script>
<html>
<head>
</head>
<body>
<form runat="server">
</form>
</body>
</html>
No way with Response.Redirect(). I... think. Maybe setting Response.Status = "200 OK" after calling Redirect() works, I've never tried.
You could fake it by setting the "Location" header manually in an otherwise empty response. Not sure what that is good for, though. ;-)
Response.AddHeader("Location", "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content)
Response.End()
(And, for the record: You would be producing an invalid HTTP header constellation. Should not break anything, but still.)
You could get this page to be redirected by javascript
Firstly, create the dynamic javascript by making the following string
<script type"text/javascript">
<!--
function redirect()
{
window.location = "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content
}
//-->
</script>
Secondly, add the javascript to the header of the current page.
Then, add javascript to body
mybody.Attributes.Add("onload", "redirect()");
When you browse the current page, it will return you HTTP 200, and after onload event fires the browser will call redirect() and your browse will be in the target page.
Just curious why do you need this?!
@eyelidlessness@
I agree it seems like a poor usability choice, but I'm hoping it's a workaround for a problem that can't be fixed directly.
Given that, try a META refresh, e.g.,
<meta http-equiv="refresh" content="5;url=http://example.com/"/>
and embed a message explaining what is going on to the unlucky user who lands on this page.
I probably didn't explain myself when posting question. This is actually a B2B transaction. There is no end-user with a browser. A third party sends the HTTP GET. All we want to do is forward it as ligitimate transaction.
Then you should send a 301 or 302 - that's the exact purpose they were designed to handle.
You can't have it both: Redirect and Status 200.
RFC2616 says about status code 200:
10.2.1 200 OK
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
- GET: an entity corresponding to the requested resource is sent in the response;
- HEAD: the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
- POST: an entity describing or containing the result of the action;
- TRACE: an entity containing the request message as received by the end server.
So there's no room for redirecting other than sending some content that is interpreted by the user agent, e.g. JavaScript to a browser.
And this is the part in the spec that tells about redirection using status codes 301, 302 or 303:
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
10.3.3 302 Found
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
10.3.4 303 See Other
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.