上下文对象里5大对象

首先在ASP.Net 里主要有5个对象看下表

系统对象	ASP.NET
Page	指向页面自身的方式。作用域为页面执行期。
Request	读取客户端在Web请求期间发送的值(http请求报文数据)
Response	封装了页面执行期返回到HTTP客户端的输出(http响应报文数据)
Application	作用于整个程序运行期的状态对象
Session	会话期状态保持对象，用于跟踪单一用户的会话。
Cookie	客户端保持会话信息的一种方式
Server	提供对服务器上的方法和属性的访问

下面我们去逐个的探讨，当然这里我们只谈这几个对象的运行原理；

 

 Requset ：它的类型HttpRequset ,

  它的主要成员：

      MapPath （）：将指定¡的虚拟路径映射到物理ª路径。

UrlReferrer( ): 请求的来源; 可以用于一些普通的防止盗链

 

 Request.UserHostAddress获得访问者的IP地址

Cookies 获取浏览器发过来的浏览器端的Cookie，从它里面读取Cookie值，比如context.Request.Cookies["mysessionid"];

使用Request.Cookies 的时候只是读取，

将Cookie写回浏览器要用Response.Cookies

   

其他成员

1、 （*） Request.AppRelativeCurrentExecutionFilePath，获取当前执行请求相对于应用根目录的虚拟路径，以~开头，比如“~/Handler.ashx”，

2、 （*） Request.PhysicalApplicationPath，获取当前应用的物理路径，比如D:\我的文档\Visual Studio 2008\WebSites\WebSite4\

3、 （*） Request.PhysicalPath，获取当前请求的物理路径，比如D:\我的文档\Visual Studio 2008\WebSites\WebSite4\Handler.ashx

4、 （*） Request.RawUrl获得原始请求URL、Request.Url获得请求的URL，区别涉及到URL重写的问题

5、 （*） Request.UserLanguages获得访问者浏览器支持的语言，可以通过这个实现对不同语言的人显示不同语言的页面。

 

  Response

  响应的缓冲输出：为了提高服务器的性能，ASP.Net向浏览器Write的时候默认并不会每Write一次都会立即输出到浏览器，而是会缓存数据，到合适的时机或者响应结束才会将缓冲区中的数据一起发送到浏览器。

l Response对象的主要成员：

• 1、Response.Buffer、Response.BufferOutput：经过Reflector反编译，发现两个属性是一样的，Buffer内部就是调用的BufferOutput。这个属性用来控制是否采用响应缓存，默认是true。

• 2、Response.Flush()将缓冲区中的数据发送给浏览器。这在需要将Write出来的内容立即输出到浏览器的场合非常适用。案例：大批量数据的导入，显示正在导入第*条数据，用Thread.Sleep模拟耗时。

• 3、Response.Clear()清空缓存区中的数据，这样在缓存区中的没有发送到浏览器端的数据被清空，不会被发送到浏览器。

• 4、Response.ContentEncoding输出流的编码。

• 5、Response.ContentType 输出流的内容类型，比如是html（text/html）还是普通文本（text/plain）还是JPEG图片（image/JPEG）。

6、Response.Cookies 返回给浏览器的Cookie的集合，可以通过它设置Cookie

7、Response.OutputStream 输出流，在输出图片、Excel文件等非文本内容的时候要使用它

8、Response.End()  终止响应，将之前缓存中的数据发给浏览器，End()之后的代码不会被继续执行,End方法里调用了Flush()方法。在终止一些非法请求的时候，比如盗链等可以用End()立即终止请求。

9、Response.Redirect(url) 重定向浏览器到新的网址。即可以重定向到站外网址也可以重定向到站内网址。Response.Redirect("http://www.rupeng.com")、Response.Redirect("a.htm")。（(信件)重寄,使改道,使改变方向的意思）

注意：Redirect是向浏览器发回302重定向(还有一个Location告诉浏览器要重定向到哪个页面)，是通知浏览器“请重新访问url这个网址”，这个过程经历了服务器通知浏览器“请重新访问url这个网址”和浏览器接到命令访问新网址的过程。使用HttpWatch查看整个响应过程的Http报文。

 

 

用Redirect因为是浏览器自己去重新访问新网址的，所以在地址栏中是可以看到网址的变化的。后面会用来防止刷新浏览器时提示“重试”。

10、Response.SetCookie(HttpCookie cookie)，向输出流中更新写到浏览器中的Cookie，如果Cookie存在就更新不存在就增加。是对Response.Cookies的简化调用。

11、Response.Write()向浏览器输出内容。

再接着是Cookie 

  

Server  

  

是一个上下文对象Httpcontext的属性，是HttpServerUtility(从字面有着工具的意思)

  所以我们简单的可以把它看成一个Httpcontext对象的辅助对象

它的成员

Server.HtmlDecode()、

Server.HtmlEncode() 

Server.UrlEncode()、

Server.UrlDecode()是对HttpUtility类中相应方法的一个代理调用。推荐总是使用HttpUtility，因为有的地方很难拿到Server对象，而且Server的存在是为以前ASP程序员习惯而留的。别把HtmlEncode、UrlEncode混了，UrlEncode是处理超链接中的中文问题， HtmlEncode是处理html代码的。还是推荐用HttpUtility.HtmlEncode。

Server.Transfer(path) 内部重定向请求，Server.Transfer(“JieBanRen.aspx”)将用户的请求重定向给JieBanRen.aspx处理，是服务器内部的接管（不能重定向到外部网站），浏览器是意识不到这个接管的，不是象Response.Redirect那样经历“通知浏览器‘请重新访问url这个网址’和浏览器接到命令访问新网址的过程”，是一次http请求，因此浏览器地址栏不会变化。因为是内部接管，所以在被重定向到的页面中是可以访问到Request、Cookies等这些来源页面接受的参数的，就像这些参数是传递给他的，而Redirect则不行，因为是让浏览器去访问的。注意Transfer是内部接管，因此不能像Redirect那样重定向到外部网站。 (常考)Response.Redirect就可以重定向到外部网站。

使用Server.Transfer不能直接重定向到ashx，否则会报错“执行子请求出错”.

有的时候不能拿到HttpContext对象,比如在Global.asax中(后面讲),可以通过HttpContext.Current拿到当前的HttpContext,进而拿到Response/Request/Server等

Server.MapPath（）的到当前的物理路径

  

 

         这就是cookie;

如果服务器两次都输出同一个名称的Cookie，浏览器会怎么办？

会将前面的Cookie覆盖掉，只保存一个；

如果服务器输出两个不同名的Cookie，浏览器怎么办？

  都会保存；

如何删除浏览器Cookie?

只要将Cookie的有效时间，改成昨天就行；

//当浏览器有两个Cookie文件：cookie:aaa@oumind.com(泛域名的Cookie)        cookie:aaa@zhaopin.oumind.com(二级域名的Cookie)

当你访问oumind.com域名时，浏览器将 cookie:aaa@oumind.com 内容发送到服务器；

当你访问的是以oumind.com结尾的域名时(如:zhaopin.oumind.com)，浏览器除了发送 cookie:aaa@zhaopin.oumind.com之外还会将cookie:aaa@oumind.com也发送到服务器。

//向Response.Cookies中添加Cookie对象的同时也向Request.Cookies集合中添加了Cookie

 

 Session（会话）

我们用一个登录实例来讲述吧

其实操作很简单，只需要几段代码

在登录页面

Session["name"]=用户名;

在主页里

If（session["name"]!=null）

{

   才把页面给用户；

}

Else

{

// 要求登录；

 }

但是我们要懂得它是怎么产生的

Web应用程序和网站

  Web应用程序缺点是每次编译时并没把前台页面类编译成程序集，当运行时才 编译；

   网站  的缺点每次不分命名空间，根据文件夹去编译成程序集，而且程序集的名字是随机的 ；

 

   以上图我们能得出：我们创建Session时 ，是在Session池里 创建，然后服务器把创建的Session对象的SessionId（这是自动分配，是唯一的）通过Cookie传给浏览器；当浏览器访问页面是，浏览器自动的将属于该网站的SessionId通过cookie传给服务器，服务器每次都会在Session池中根据传过来的SessionId找到对应的Session对象，判断是否存在这个SessionId所对应的Session，而这个操作并非创建完页面对象后，才去判断，如果是这样，那么之前的：If（session["name"]!=null）不起作用了； 

  在详细一点 之前的这个操作是在HttpApplication ProcessRequest()请求管道的第九个事件里根据之前的操作，把Session对象赋给当前页面的对象Application的上下文对象Context的；

还有一个不可遗漏的在此之前会判断有没有实现IRequiresSessionState  如果实现了就加Session ，问题：（那么你会发现在Webfrom中不需要实现这个接口 ？ 为什么呢？ ）它在编译期就把接口的实现加进来的 有Refector 工具得出，但是当

  Session .Abandou() 销毁在服务器中所对应的的Session对象；

Session.Clear()；清空Session池里的键值对；

Timeout 超时时间 默认是20分钟

、；

Session 有三种 

进程内的Session ；

   上面

进程外的Session；

数据库Session；

Application对象

   类型为ApplicatonState

Application.Lock();

Application["lala"]="hahaha";

Application.UnLock();

一次只能有一个去访问；以上代码可看出当访问和操作的时候 ，先枷锁，操作完就解锁； 这解决当很多用户去访问时，每次只能有一个访问

整个请求管道，公用一个；