標籤: 網站設計

前言

有些時候我們會發現方法名稱都正確匹配，但就是找不到對應請求接口，所以本文我們來深入了解下何時會出現接口請求404的情況。

匹配控制器Action方法（404）

首先我們創建一個web api應用程序，我們給出如下示例控制器代碼

[ApiController]
[Route("[controller]/[action]")]
public class WeatherController : ControllerBase
{
    [HttpGet]
    string Get()
    {
        return "Hello World";
    }
}

 

當我們進行如上請求時會發現接口請求不到，這是為何呢？細心的你應該可能發現了，對於請求方法是私有，而不是公共的，當我們加上public就可以請求到了接口

[HttpGet("get")]
public string Get()
{
    return "Hello World";
}

匹配控制器Action方法本質

經過如上示例，那麼對於Action方法的到底要滿足怎樣的定義才能夠不至於請求不到呢？接下來我們看看源碼怎麼講。我們找到DefaultApplicationModelProvider類，在此類中有一個OnProvidersExecuting方法用來構建控制器和Action方法模型，當我們構建完畢所有滿足條件的控制器模型后，緊接着勢必會遍歷控制器模型去獲取對應控制器模型下的Action方法，這裏只截取獲取Action方法片段，源碼如下：

foreach (var controllerType in context.ControllerTypes)
{    
    //獲取控制器模型下的Action方法
    foreach (var methodInfo in controllerType.AsType().GetMethods())
    {
        var actionModel = CreateActionModel(controllerType, methodInfo);
        if (actionModel == null)
        {
            continue;
        }

        actionModel.Controller = controllerModel;
        controllerModel.Actions.Add(actionModel);    
    }
}

上述紅色標記則是創建Action模型的重點，我們繼續往下看到底滿足哪些條件才創建Action模型呢？

protected virtual ActionModel CreateActionModel(TypeInfo typeInfo, MethodInfo methodInfo)
{
    if (typeInfo == null)
    {
        throw new ArgumentNullException(nameof(typeInfo));
    }

    if (methodInfo == null)
    {
        throw new ArgumentNullException(nameof(methodInfo));
    }

    if (!IsAction(typeInfo, methodInfo))
    {
        return null;
    }    
    ......    
}

到了這個方法裏面，我們找到了如何確定一個方法為Action方法的源頭，由於該方法有點長，這裏我採用文字敘述來作為判斷邏輯，如下：

protected virtual bool IsAction(TypeInfo typeInfo, MethodInfo methodInfo)
{
    //如果有屬性訪問器（無效）

    //如果有NonAction特性標識無效）

    //如果重寫Equals(Object), GetHashCode()方法（無效）

    //如果實現Dispose方法（無效）

    //如果是靜態方法（無效）

    //如果是抽象方法（無效）

    //如果是構造函數（無效）

    //如果是泛型方法（無效）

    //必須為公共方法
    return methodInfo.IsPublic;
}

如上是從方法定義的角度來過濾而獲取Action方法，除此之外，我們請求方法的名稱還可以自定義，比如通過路由、ActionName特性指定，那麼這二者是否存在優先級呢？比如如下示例：

[ApiController]
[Route("[controller]/[action]")]
public class WeatherController : ControllerBase
{
    [HttpGet]
    [ActionName("get1")]
    public string get()
    {
        var routeValue = HttpContext.Request.RouteValues.FirstOrDefault();

        return routeValue.Value.ToString();
    }
}

我們可以看到此時將以ActionName特性作為方法名稱。所以在上述過濾方法定義后開始構建方法模型，在此之後還會再做一步操作，那就是查找該方法是否通過ActionName特性標識，若存在則以ActionName特性標識給定的名稱作為請求方法名稱，否則以方法定義名稱為準，源碼如下：

var actionModel = new ActionModel(methodInfo, attributes);

AddRange(actionModel.Filters, attributes.OfType<IFilterMetadata>());

var actionName = attributes.OfType<ActionNameAttribute>().FirstOrDefault();
if (actionName?.Name != null)
{
    actionModel.ActionName = actionName.Name;
}
else
{
    actionModel.ActionName = methodInfo.Name;
}

還沒完，若是將路由特性放到Action方法上，如下，此時請求接口應該是weather/get還是weather/get1呢？

[ApiController]
public class WeatherController : ControllerBase
{
    [HttpGet]
    [Route("weather/get")]
    [ActionName("get1")]
    public string get()
    {
        var routeValue = HttpContext.Request.RouteValues.FirstOrDefault();

        return routeValue.Value.ToString();
    }
}

此時若我們以weather/get1請求將出現404，還是以路由特性模板給定為準進行請求，但最終會將路由上Action方法名稱通過ActionName特性上的名稱賦值給Action模型中的ActionName進行覆蓋，源碼如下，所以上述我們得到的action名稱為get1，，當然這麼做沒有任何實際意義。

public static void AddRouteValues(ControllerActionDescriptor actionDescriptor,ControllerModel controller,ActionModel action)
{
    foreach (var kvp in action.RouteValues)
    {
        if (!actionDescriptor.RouteValues.ContainsKey(kvp.Key))
        {
            actionDescriptor.RouteValues.Add(kvp.Key, kvp.Value);
        }
    }

    if (!actionDescriptor.RouteValues.ContainsKey("action"))
    {
        actionDescriptor.RouteValues.Add("action", action.ActionName ?? string.Empty);
    }

    if (!actionDescriptor.RouteValues.ContainsKey("controller"))
    {
        actionDescriptor.RouteValues.Add("controller", controller.ControllerName);
    }
}

總結

本文我們只是單獨針對查找Action方法名稱匹配問題做了進一步的探討，根據源碼分析，對Action方法名稱指定會做3步操作：第一，根據方法定義進行過濾篩選，第二，若方法通過AcionName特性標識則以其所給名稱為準，否則以方法名稱為準，最終賦值給ActionModel上的ActionName屬性，第三，將ActionModel上的ActionName值賦值給路由集合中的鍵Action。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

Promise 是異步編程的一種解決方案。

Promise

/**
 * 屬性
 */
Promise.length
Promise.prototype

/**
 * 方法
 */
Promise.all(iterable)   // 所有成功觸發成功  任何失敗觸發失敗
Promise.race(iterable)  // 任意一個成功或失敗后觸發
Promise.reject(reason)
Promise.resolve(value)

/**
 * 原型
 */
Promise.prototype.constructor
//方法
Promise.prototype.catch(onRejected)
Promise.prototype.then(onFulfilled, onRejected)
Promise.prototype.finally(onFinally)

Promise 有三種狀態

• pending: 初始狀態，既不是成功，也不是失敗狀態。
• resolve: 意味着操作成功完成。(resoloved)
• reject: 意味着操作失敗。

pending

pending 是初始狀態，執行 resolve/reject 會進入對應狀態，如果不執行，責一直為 pending 狀態

例如下面代碼，promise 將一直在 pending 狀態，不會執行 then/catch.

new Promise(function (resolve, reject) { })
  .then(res => console.log(res))
  .catch(err => console.log(err))

resolve

resolve 意味着操作成功完成, 如果有 .then，值會傳入 .then 的第一個參數函數里。

如

new Promise(function (resolve, reject) {
  resolve(1)
})
  .then(res => console.log(res))

then 的第一個參數是成功的回調，第一個參數的返回值會影響接下來鏈的去向。第一個參數的返回值一般有三種情況

• 無返回值：會去執行下一個 .then ，沒有參數
• 返回值非promise：調用下一個then的函數，參數為返回值
• 返回值為promise：根據promise的執行結果，執行 下一個then/catch，如果一直是pending，則不執行下一個then/catch

例如想要在當前 then 終止，可以這樣操作：

  .then((res) => new Promise(() => {}))

reject

reject 意味着操作失敗。

使用 .catch 會捕獲到錯誤信息。

與代碼報錯(如 undefined.a)不同的是, 代碼報錯如果不使用 catch 捕獲，會向外傳遞，最終傳遞到根結點；而 reject 屬於 promise 錯誤，即使不使用 catch 捕獲也不會對全局有影響。

用 promise 實現 fetch

先來看幾個問題：

1. 如果請求 code 404, 會走 then 還是 catch? (答案：then)
2. 控制台能看到一行 404 的錯誤, 為什麼還是走 then 不是 catch 呢
3. 如果請求跨域失敗，走 then 還是 catch?（答案：catch）
4. 同樣是控制台看到錯誤，兩者有什麼區別呢?
5. 跨域失敗的報錯, 和 then 中 undefined.a 報錯，如果都不 catch，後者在 react 腳手架開發環境頁面會蹦，兩者有什麼區別?

帶着這幾個問題，來看看 fetch。

fetch 返回值是 promise，所以有三種狀態 pending、resolve、reject.

• pending: 請求中
• resolve: 請求成功（code 200/404/500 等, 非 200 控制台輸出錯誤）
• reject: 請求失敗（跨域失敗、連接超時、無網絡等，控制台輸出錯誤）

我們還發現，請求失敗時，只能 catch 到最後一行錯誤, 如圖

捕獲后

為什麼 404 在控制台看到錯誤，還走 then, resolve 如何實現

實現有幾個難點，

1. throw 後面代碼不會執行;
2. 先報錯，后執行 then；
3. catch 后錯誤不會打印在控制台；

試了下，Promise.reject(‘xxx’) 這樣的報錯方式雖然是微觀任務，但是總是在.then之後才在控制台輸出，更像是宏觀任務。所以也加個setTImeout宏觀任務調至後面。

var fetch = function () {
  return new Promise(function (resolve, reject) {
    setTimeout(function () {
      if ('請求成功 200') {
        resolve('Response數據結構');
      } else if ('請求成功 404，500等') {
        Promise.reject('GET xxxxxxxx 404');
        setTimeout(function () {
          resolve('Response數據結構');
        });
      }
    })
  })
}

請求失敗 例如跨域失敗 reject 如何實現呢

同樣加個 setTimeout

var fetch = function () {
  return new Promise(function (resolve, reject) {
    setTimeout(function () {
      if ('請求成功 200') {
        resolve('Response數據結構');
      } else if ('請求成功 404，500等') {
        Promise.reject('GET xxxxxxxx 404');
        setTimeout(function () {
          resolve('Response數據結構');
        });
      } else if ('請求失敗') {
        Promise.reject('Access to fetch xxxxx with CORS disabled.');
        Promise.reject('GET xxxxx net::ERR_FAILED');
        setTimeout(function () {
          reject('TypeError: Failed to fetch');
        });
      }
    })
  })
}

還是有些問題，我們實現的因為在promise 中，錯誤會有前綴 Uncaught (in promise)。瀏覽器客戶端應該有更好的實現方式。

最後總結一下 fetch 的三種情況

• pending: 請求中
• resolve: 請求成功（code 200: 調用 resolve 返回數據； code: 404/500 等, 先拋錯，再調用 resolve 返回數據。）
• reject: 請求失敗（跨域失敗、連接超時、無網絡等，先控制台拋錯，再調用 reject）

拋錯均不影響代碼執行，與 undefined.a 不同。

whosmeya.com

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

*文章來源：https://blog.egsec.cn/archives/601

*本文將主要說明：本文主要敘述什麼是DNS、域名的層級、DNS 解析過程、DNS的緩存時間、DNS 的記錄類型、DNS 報文結構、DNS劫持與HTTP劫持以及手動清理本地緩存的方法。

 

DNS屬於應用層。DNS即域名系統，其作用是將字符串域名解析成相對於的服務器IP地址，免除人們記憶IP地址的單調和苦惱，屬於為用戶排憂解難之舉，因此劃歸為應用層。DNS不屬於協議,它是域名解析。

 

什麼是DNS

DNS是 Domain Name System 的縮寫，也就是 域名解析系統，它的作用非常簡單，就是根據域名查出對應的 IP地址。

你可以把它想象成一本巨大的電話本，比如當你要訪問域名www.egsec.cn，首先要通過DNS查出它的IP地址是118.31.61.137。

域名層級

DNS 的解析過程中，需要對域名的層級有了解：

• 根域名 ：.root 或者 . ，通常是省略的
• 頂級域名，如 .com，.cn 等
• 次級域名，如 baidu.com 里的 baidu，這個是用戶可以進行註冊購買的
• 主機域名，比如 baike.baidu.com 里的baike，這個是用戶可分配的 

主機名.次級域名.頂級域名.根域名
baike.baidu.com.root

DNS 解析過程

咱們以訪問 www.egsec.cn 這個域名為例，來看一看當你訪問 www.egsec.cn 時，會發生哪些事：

1. 先查找本地 DNS 緩存（自己的電腦上），有則返回，沒有則進入下一步
2. 查看本地 hosts 文件有沒有相應的映射記錄，有則返回，沒有則進入下一步
3. 向本地 DNS 服務器（一般都是你的網絡接入服務器商提供，比如中國電信，中國移動）發送請求進行查詢，本地DNS服務器收到請求后，會先查下自己的緩存記錄，如果查到了直接返回就結束了，如果沒有查到，本地DNS服務器就會向DNS的根域名服務器發起查詢請求：請問老大， www.egsec.cn 的ip是啥？
4. 根域名服務器收到請求后，看到這是個 .cn 的域名，就回信說：這個域名是由 .cn 老弟管理的，你去問他好了，這是.cn老弟的聯繫方式（ip1）。
5. 本地 DNS 服務器接收到回信后，照着老大哥給的聯繫方式（ip1），馬上給 .cn 這個頂級域名服務器發起請求：請問 .cn 大大，www.egsec.cn 的ip 是啥？
6. .cn 頂級域名服務器接收到請求后，看到這是 egsec.cn 的域名，就回信說：這個域名是 .egsec.cn 老弟管理的，你就去問他就行了，這是他的聯繫方式（ip2）
7. 本地 DNS 服務器接收到回信后，按照前輩的指引（ip2），又向 .egsec.cn 這個權威域名服務器發起請求：請問 egsec.cn 大大，請問 www.egsec.cn 的ip是啥？
8. egsec.cn 權威域名服務器接收到請求后，確認了是自己管理的域名，馬上查了下自己的小本本，把 www.egsec.cn 的ip告訴了 本地DNS服務器。
9. 本地DNS服務器接收到回信后，非常地開心，這下總算拿到了www.egsec.cn的ip了，馬上把這個消息告訴了要求查詢的客戶（就是你的電腦）。由於這個過程比較漫長，本地DNS服務器為了節省時間，也為了盡量不去打擾各位老大哥，就把這個查詢結果偷偷地記在了自己的小本本上，方便下次有人來查詢時，可以快速回應。

總結起來就是三句話:

• 從”根域名服務器”查到”頂級域名服務器”的NS記錄和A記錄（IP地址）
• 從”頂級域名服務器”查到”次級域名服務器”的NS記錄和A記錄（IP地址）
• 從”次級域名服務器”查出”主機名”的IP地址

DNS的緩存時間

上面的幾個步驟里，可以看到有兩個地方會緩存 DNS 的查詢記錄，有了緩存，在一定程度上會提高查詢效率，但同時在準確率上會有所損失。

因此我們在配置 DNS 解析的時候，會有一個 TTL 參數（Time To Live），意思就是這個緩存可以存活多長時間，過了這個時間，本地 DNS 就會刪除這條記錄，刪除了緩存后，你再訪問，就要重新走一遍上面的流程，獲取最新的地址。

DNS 的記錄類型

當我們在阿里雲買了一個域名后，可以配置我們主機域名解析規則，也就是 記錄。  

阿里雲域名雲解析（不管是哪個服務商都一樣）：

常見的 DNS 記錄類型如下

• A：地址記錄（Address），返回域名指向的IP地址。
• NS：域名服務器記錄（Name Server），返回保存下一級域名信息的服務器地址。該記錄只能設置為域名，不能設置為IP地址。
• MX：郵件記錄（Mail eXchange），返回接收电子郵件的服務器地址。
• CNAME：規範名稱記錄（Canonical Name），返回另一個域名，即當前查詢的域名是另一個域名的跳轉，詳見下文。
• PTR：逆向查詢記錄（Pointer Record），只用於從IP地址查詢域名，詳見下文。

DNS報文結構

1. 事務 ID：DNS 報文的 ID 標識。對於請求報文和其對應的應答報文，該字段的值是相同的。通過它可以區分 DNS 應答報文是對哪個請求進行響應的。
2. 標誌：DNS 報文中的標誌字段。
3. 問題計數：DNS 查詢請求的數目。
4. 回答資源記錄數：DNS 響應的數目。
5. 權威名稱服務器計數：權威名稱服務器的數目。
6. 附加資源記錄數：額外的記錄數目（權威名稱服務器對應 IP 地址的數目）

DNS劫持與HTTP劫持

通過上面的講解，我們都知道了，DNS 完成了一次域名到 IP 的映射查詢，當你在訪問 www.egsec.cn 時，能正確返回給你 我網站首頁的 ip。

但如果此時 DNS 解析出現了一些問題，當你想要訪問 www.egsec.cn 時，卻返回給你 www.baidu.com 的ip，這就是我們常說的 DNS 劫持。

與之容易混淆的有 HTTP 劫持。

什麼是 HTTP 劫持？

你一定見過當你在訪問 某個網站時，右下角也突然彈出了一個扎眼的廣告彈窗。這就是 HTTP 劫持。

藉助別人文章里的例子，它們倆的區別就好比是

• DNS劫持是你想去機場的時候，把你給丟到火車站。
• HTTP劫持是你去機場途中，有人給你塞小廣告。

DNS劫持 是如何產生的？

下面大概說幾種DNS劫持方法：

1.本機DNS劫持

攻擊者通過某些手段使用戶的計算機感染上木馬病毒，或者惡意軟件之後，惡意修改本地DNS配置，比如修改本地hosts文件，緩存等

2. 路由DNS劫持

很多用戶默認路由器的默認密碼，攻擊者可以侵入到路由管理員賬號中，修改路由器的默認配置

3.攻擊DNS服務器

直接攻擊DNS服務器，例如對DNS服務器進行DDOS攻擊，可以是DNS服務器宕機，出現異常請求，還可以利用某些手段感染dns服務器的緩存，使給用戶返回來的是惡意的ip地址

如何在本地查詢 DNS 解析結果？

nslookup命令：

命令格式：nslookup [查詢的域名] [指定DNS服務器]

你也可以指定公網的域名服務器進行查詢，比如常見的 114.114.114.114

手動清理DNS緩存

MacOS：

sudo dscacheutil -flushcache
$ sudo killall -HUP mDNSResponder

Windows：

$ ipconfig /flushdns

Linux：

使用NSCD的DNS緩存
$ sudo /etc/init.d/nscd restart

# 服務器或者路由器使用DNSMASQ
$ sudo dnsmasq restart

　　

DNS詳解篇完

轉發請註明出處(EG Blog：blog.egsec.cn)，謝謝！

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

  近日美國電動車廠 Tesla 宣布與荷蘭當地租車公司合作，提供阿姆斯特丹 Schiphol 機場旅客 Model S 租車方案。   對於素有「腳踏車烏托邦」美名之稱的荷蘭而言，出門不開車不是一個選項，而是一個自然不過的習慣，甚至推行各項自然發電方式，其中阿姆斯特丹更是打造成低碳城市，在政府的綠能政策下，電動的推行早已行之有年。   而這次由荷蘭 BBF Schipholtaxi 與 BIOS-groep 兩大租車公司通力合作，一口氣導入 167 輛特斯拉 Model S 加入汽車租賃，以首都阿姆斯特丹主要機場史基浦（Schiphol）國際機場作為出租據點，鎖定國際旅客與國內高端客群，也替低碳城市計畫盡一份心力。     （Source：）  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準