一直不甚了解HttpContext的含义,平时也用的很少,但是它在ASP时代就已经是内置的Web开发的六大对象之一。
今天看了一篇文章,ASP.NET如何保持用户状态,其上有一些关于HttpContext的介绍:保持单个用户、单个请求的数据,并且数据只在该请求期间保持。被提供用于保持需要在不同的HttpModules和HttpHandlers之间传递的值。它也可以用于保持某个完整请求的相应信息。
再结合它提供的RewriteUrl方法来看,似乎有些明白:当用户发送某个Http请求,我们可以通过HttpContext进行截获,查看里面包含了哪些请求的信息,然后可以进行一系列的操作,比如说切换到其他的页面,这个时候,可以重组请求的数据满足新页面的要求。
举例如下,尽管未必恰当:
某个网站经销传统的印刷品、并且提供有偿的电子书籍的销售,二者使用的展示流程是一致的,但是这两类商品的销售管理流程是不同的。
http://www.cn-web.com/link.aspx?id=12345&NeedCounnt=5 (id表示商品的编号,NeedCount表示需要的数量,针对电子产品其不存在意义,因为电子产品是可Copy的)
那么在link.aspx中需要判断是进入哪一种的采购流程,切换到不同的页面 PrintBook.aspx 或者 EBook.aspx。
所以这个Http请求需要涉及两个页面,针对每个页面link.aspx和printBook.aspx或者EBook.aspx都会各自存在一个httpRequest,但是却共用同一个httpContext。
切换需要使用Server.Transfer方法,〔直接在Server上进行其他页面的调用,保证是同一个HttpContext,信息不会丢失。〕。而不是Response.Redirect(它是将Response发送回浏览器,然后浏览器再发送了一个新的请求给目标页面,是两个不同的HttpContext了)。
//Link.aspx 检查 商品的类型进行切换
protected void Page_Load(object sender,EventArgs e)
{
string sType = GetProductType(Request["id"].ToString());
//id参数写入Context中
Context.Items.Add("id",Request["id"]);
if(sType=="print")
{
Context.Items.Add("NeedCount",Request["NeedCount"]);
//不需要写Url+参数的形式
Server.Transfer("PrintBook.aspx");
}
else
{
Server.Transfer("EBook.aspx");
}
}
//PrintBook.aspx 获得相关的数据,继续其他的操作
protected void Page_Load(object sender,EventArgs e)
{
//从Context中获得参数
Response.Write(Context.Items["id"]);
}
而Rewriterpath方法是指重写请求的路径,并不是转换页面,因为通常Http请求的Url不一定对应有相关的页面,那么在Application_BeginRequest中去检查Url请求,如果符合一定条件就可以RewritePath,就是将莫须有的Url请求对应出存在的页面。
比如说通常的404 Page Not Found,有些网站会提供很有趣的页面,就是这样的实现机制。当然这种机制是WebServer来实现的,原理是相同的。
另外,很多的Blog程序也是这个道理,请参考。
个人体会,RewritePath在页面中进行操作是失效的,也许这个时候调用它太迟了。不过这篇文章有另外的说法:使用 HttpContext.RewritePath 来配合 Server.Transfer/Execute
Current是HttpContext的一个很有用的静态属性,所以即使不在Page页面中,也可以通过这个属性来获得当前的Web状态。