1. Context 名詞解析
Context 直接翻譯就是上下文。"上下文" 這個名詞仍是挺讓人費解的,是一個很是泛化的概念。剛看到有點讓人摸不着頭腦,一個高端大氣上檔次的名詞,若是要找一個相似的解釋能夠是咱們讀文章會用到的語境。
咱們講個「語境」 與「上下文」的例子,可能能夠幫助理解。好比「他是揹着包袱離開家的,」「包袱」在這裏面有點歧義。 這句話能夠理解爲「他揹着一包東西離開了家」,也能夠說「他帶着思想負擔離開了家」,在這裏詞語「包袱」只有藉助特定的語境才能肯定其真正含義。 那麼咱們在 web 中常常使用到的Session , 也是這樣的, 單單給你一個Session,你是沒有辦法知道具體的含義的,每一個請求過來的 Session可能都會不同,可能有些裏面就沒有值,只有在運行時每一次請求上下文中咱們獲取的這個Session的值纔是有意義的。
2. HttpContext 的簡單介紹
首先咱們來看一下這個類的定義,這裏面只是截取了部分,標紅的是咱們常常用到的,有些是每一次請求必需要用到的,既然我用了請求這個詞,那就是對應的 HttpRquest。有請求就會有返回,這個就是HttpReponse。
咱們首先看一下 命名空間 System.Web,這個只要稍微知道一下,有時咱們要用一個 api 常常不知道它所在的命名空間。
HttpRequest 的定義
這個是與請求有關的全部參數,看這個主要是瞭解 Request 的大概內容。 若是你要獲取一個跟瀏覽器有關的信息,好比cookie 的值,那你應該從這個地方來找一下有沒有,若是連這個地方都沒有,那很大可能性,你是沒有辦法獲得的。固然 cookie這邊是有的。再看一下QuertString上面 有具體的使用方法,這些方法不是我本身寫上去的,是api裏面自帶的,告訴你怎麼使用的,這些關注一下,能夠加深你對一個api的記憶。 當你不知道一個api怎麼用的時候,先去定義裏面看一下關於這個api的各類信息,裏面總歸有一個是適合你的,若是實在找不到,能夠考慮一下你要找的信息是否是在其餘api裏面,與HttpRequest 有關嗎,好比你要指定返回信息的字符集,那應該到 HttpReponse 裏面去找,咱們不能用一個化學方程式來解決一個牛頓力學問題,不過好像如今大部分汽車的能量來源是化石燃料,化學方程式可能也能夠處理物理問題。
HttpReponse 的定義
這個是與返回有關的全部參數,若是你要指定返回的字符集,那你能夠指定 Charset。
咱們發現HttpReponse裏面也有一個 Cookies,那麼這個 Cookies 和 HttpRequest 是同一個嗎?若是你有答案了能夠驗證一下。
var requestCookie = HttpContext.Current.Request.Cookies;
var reponseCookie = HttpContext.Current.Response.Cookies;
var b = requestCookie.Equals(reponseCookie);
3 . HttpContext 總結
經過上面的兩個例子,給咱們的感受 Context 有點像一個倉庫,咱們須要什麼就能夠去裏面拿,若是在這裏面也找不到.,那其餘地方就很難再找到了。下面咱們從新認識一下HttpContext。
HttpContext 就是關於 Http請求過程當中涉及到的全部變量或者引用存放的一個倉庫。 相似的咱們還有 DbContext, ApplicationContext 。在這裏面咱們提到了 「上下文」、「倉庫」 這些名詞,在這篇文章的邊界以內,指代的就是 Context 這個概念。
4. 小思考
既然咱們知道了這些,那就給你出個小題目唄,若是要獲取用戶的 IP 那應該從哪裏去找,可能有時候獲取的值跟你想象的不同,應用服務器前面有了一層反向代理服務器好比 Nginx , 會不會影響咱們這種方式取IP地址呢,這時咱們該怎麼辦。
這裏面涉及到一個小定義
X-Forwarded-For:簡稱XFF頭,它表明客戶端,也就是HTTP的請求端真實的IP,只有在經過了HTTP 代理或者負載均衡服務器時纔會添加該項。它不是RFC中定義的標準請求頭信息,在squid緩存代理服務器開發文檔中能夠找到該項的詳細介紹。標準格式以下:X-Forwarded-For: client1, proxy1, proxy2
var headers = HttpContext.Current.Request.Headers;
var forward = headers["X-Forwarded-For"];
forward 記錄完整的代理鏈路。