0

我希望此页面返回 200，同时仍发送重定向...

<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>
4

4 回答 4

2

@无眼睑@

我同意这似乎是一个糟糕的可用性选择，但我希望这是解决无法直接修复的问题的一种解决方法。

鉴于此，请尝试META refresh，例如，

<meta http-equiv="refresh" content="5;url=http://example.com/"/>

并嵌入一条消息，向登陆此页面的不幸用户解释正在发生的事情。

发布问题时我可能没有解释自己。这实际上是一个 B2B 交易。没有最终用户使用浏览器。第三方发送 HTTP GET。我们要做的就是将其作为合法交易转发。

然后你应该发送一个 301 或 302——这正是他们设计处理的目的。

于 2008-10-28T10:00:38.990 回答
1

你可以让这个页面被javascript重定向

首先，通过制作以下字符串来创建动态javascript

<script type"text/javascript">
<!--
function redirect()
{
   window.location = "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content
}
//-->
</script>

其次，将javascript添加到当前页面的标题中。

然后，将javascript添加到正文

mybody.Attributes.Add("onload", "redirect()");

当您浏览当前页面时，它将返回 HTTP 200，并且在 onload 事件触发后，浏览器将调用 redirect() 并且您的浏览将在目标页面中。

只是好奇你为什么需要这个？！

于 2008-10-28T06:10:49.017 回答
1

你不能同时拥有它：重定向和状态 200。

RFC2616说关于状态码 200：

10.2.1 200 正常

请求已成功。响应返回的信息取决于请求中使用的方法，例如：

  • GET : 在响应中发送对应于请求资源的实体；
  • HEAD：请求资源对应的实体头字段在响应中发送，不带任何消息体；
  • POST：描述或包含动作结果的实体；
  • TRACE：包含由终端服务器接收到的请求消息的实体。

因此，除了发送一些由用户代理解释的内容（例如 JavaScript）到浏览器之外，没有重定向的空间。

这是规范中关于使用状态码 301、302 或 303 进行重定向的部分：

10.3.2 301 永久移动

请求的资源已被分配一个新的永久 URI，并且任何将来对该资源的引用都应该使用返回的 URI 之一。如果可能，具有链接编辑功能的客户端应该自动将对 Request-URI 的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。

新的永久 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。

如果收到 301 状态代码以响应 GET 或 HEAD 以外的请求，除非用户可以确认，否则用户代理不得自动重定向请求，因为这可能会改变发出请求的条件。

注意：当收到 301 状态码后自动重定向 POST 请求时，一些现有的 HTTP/1.0 用户代理会错误地将其更改为 GET 请求。

10.3.3 302 找到

请求的资源临时驻留在不同的 URI 下。由于重定向有时可能会改变，客户端应该继续使用 Request-URI 来处理未来的请求。此响应仅在由 Cache-Control 或 Expires 标头字段指示时才可缓存。

临时 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。

如果收到 302 状态代码以响应 GET 或 HEAD 以外的请求，除非用户可以确认，否则用户代理不得自动重定向请求，因为这可能会改变发出请求的条件。

注意：RFC 1945 和 RFC 2068 指定不允许客户端更改重定向请求的方法。然而，大多数现有的用户代理实现将 302 视为 303 响应，无论原始请求方法如何，都对 Location 字段值执行 GET。状态码 303 和 307 已被添加用于希望明确明确期望客户端做出何种反应的服务器。

10.3.4 303 见其他

可以在不同的 URI 下找到对请求的响应，并且应该使用该资源上的 GET 方法来检索。此方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源。新的 URI 不是原始请求资源的替代引用。303 响应不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。

不同的 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。

注意：许多 HTTP/1.1 之前的用户代理不理解 303 状态。当与此类客户端的互操作性是一个问题时，可以使用 302 状态代码代替，因为大多数用户代理对 302 响应做出反应，如此处针对 303 所述。

于 2008-11-03T20:12:11.570 回答
0

没办法Response.Redirect()。我认为。也许Response.Status = "200 OK"调用后设置Redirect()有效，我从未尝试过。

您可以通过在其他空响应中手动设置“位置”标头来伪造它。不过，不确定这有什么好处。;-)

Response.AddHeader("Location", "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content)
Response.End()

（并且，为了记录：您将产生一个无效的 HTTP 标头星座。不应该破坏任何东西，但仍然。）

于 2008-10-28T06:00:04.623 回答