Nodejs Express 4.X 中文API 2--- Request篇

相關閱讀： <a href="http://www.cnblogs.com/ae6623/p/4433048.html" target="_blank"> Express 4.X API 翻譯[一] --  Application篇</a>

這是一個包含着被命名的路由規則“參數”的對象屬性。例如如果你有一個路由規則為：”/user/:name”,然後這個”name”屬性你就可以使用req.params.name來調用，這個屬性預設為 {}

當在定義路由規則的時候使用了正規表達式，比對結果會被提供在數組裡使用req.params[N]，這裡的N指的是第n個比對數組。這樣的規則被應用在使用未命名的通配比對規則，例如<code>/file/*</code>；

這個屬性是一個對象屬性包含着被解析過的請求參數對象，預設為{}

這個屬性是包含一個被解析過的請求體。這個功能是中間件 bodyParser 提供的，盡管其他的請求體解析中間件也會很好的支援這樣的約定。這個屬性會在使用了bodyParser()的時候被定義為{}。

傳回一個參數名為 name 的值

查找的優先級如下：

req.params

req.body

req.query

直接通路 req.body , req.params,和 req.query 應該是更加的清晰，除非你确實需要接受每個對象的輸入。

目前比對的 “Route” 包含一些屬性，例如路由的原始字元串以及轉換後的正規表達式等。

上面的例子将會輸出以下内容：

當cookieParser()中間件被使用的時候，這個對象将會被初始化為{}，除此之外，還包含了由使用者代理發送過來的cookies

當 cookieParser(secret)中間件被執行的時候，這個對象會被初始化為{}，還包含了使用者代理發送過來的被簽名的cookie，未簽名的和準備使用的。簽名後的cookies被存放在一個單獨的對象内，否則，攻擊者會很輕松的替換掉”req.cookie”内的值。需要注意的是，簽名的cookies并不帶表它們是隐藏的或者是加密的，這個隻是同于防止篡改cookies。

擷取請求頭内的 field 字段，不區分大小寫，其中Referrer 和 Referer字段是可互換的。

别名為 req.header(field);

檢查給定的類型 types 是不是可以接受的類型，當是可接受的類型時傳回最佳的比對，否則傳回 undefined – 在這種情況下，你應該傳回406″Not Acceptable”。

type 的值可以是單一的一個mine類型的字元串，比如”application/json”,擴充名為”json”，也可以是一個以逗号分隔的清單或者數組。當為清單或數組時将傳回最佳比對。

檢查給定的 charset是否是可以被接受的

檢查給定的 lang 是否為可接受的

檢查送出進來的請求是否包含”Content-Type”頭字段和他比對的給定的mime type

傳回遠端位址，或者在反向代理啟用時傳回上遊ip位址。

當反向代理模式開啟時，解析 “X-Forwarded-For” ip位址清單并傳回一個數組，否則傳回空數組。例如，如果一個值為”client,proxy1,proxy2″你将會收到數組["client","proxy1","proxy2"]這裡可以看出”proxy2″是最遠的下遊位址。

傳回請求的URL路徑名。

傳回從“Host”請求内取出的主機名，但是不包含端口号。

檢查請求是否是新的 – 通過對Last-Modified或者 ETag進行比對，來标明這個資源是不是”新的”。

檢查這個請求是不是舊的 – 如果Last-Modified 或者 ETag 不比對，标明這個資源是舊的。

檢查請求頭裡是否有”X-Requested-With”這樣的字段并且值為”XMLHttpRequest”(jQuery 等)請求時會設定這個頭

傳回請求協定字元串 “http”或者”https”當請求為TLS時。當被啟用反向代理時，”X-Forwarded-Proto” 請求頭将會被信任。如果你運作一個支援https協定的反向代理，那麼這個是會被支援的。

檢查TLS連接配接是否已經被建立。下面是一段簡寫

傳回子域名數組

這個屬性很像req.url,然而，他保留了原始請求的url，允許你在做内部路由的時候自由的重寫 req.url。例如，app.use()會重寫 req.url 為挂載點