一直不甚了解HttpContext的含义，平时也用的很少，但是它在ASP时代就已经是内置的Web开发的六大对象之一。
今天看了一篇文章，ASP.NET保持用户状态的九种选择，其上有一些关于HttpContext的介绍：保持单个用户、单个请求的数据，并且数据只在该请求期间保持。被提供用于保持需要在不同的HttpModules和HttpHandlers之间传递的值。它也可以用于保持某个完整请求的相应信息。
再结合它提供的RewriteUrl方法来看，似乎有些明白：当用户发送某个Http请求，我们可以通过HttpContext进行截获，查看里面包含了哪些请求的信息，然后可以进行一系列的操作，比如说切换到其他的页面，这个时候，可以重组请求的数据满足新页面的要求。
举例如下,尽管未必恰当：
某个网站经销传统的印刷品、并且提供有偿的电子书籍的销售，二者使用的展示流程是一致的，但是这两类商品的销售管理流程是不同的。
http://www.domain.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状态。
相关文章：
MSDN关于上下文 介绍了一些小技巧，比如说如何最简单的生成标准的也美、页脚
在ASP.NET中执行URL重写
在ASP.NET中使用NHibernate 这个关于Context的应用，更高级了一点
asp.net forums中定时器的应用
ASP.Net中自定义Http处理及应用
编写高性能WEB应用程序的10个技巧