ASP.NET MVC構建RESTful服務時返回Unauthorized(401)狀態

這兩天在構建RESTful服務的用戶端，本以為已經一馬平川了，沒有想到就在下班時遇到一個問題。

我打算在伺服器商把所處理的HTTP異常狀態(400-599))狀態一一返回給用戶端組件，用戶端收到各個狀態代碼後根據號碼及從伺服器端返回的Description Content來拋出用戶端的異常，結果在測試401時發現一個問題：在我的設想中，收到401，然後再去讀取Response中的Status Description(我使用了自訂格式，詳見上篇博文)，結果出乎意料的是，伺服器端發出了401，結果用戶端沒有拋出異常，而且按照接收成功的狀態去了讀取ATOM Feed的代碼，而解析ATOM Feed時報錯了，這讓我很是詫異，經查看HttpStatusCode發現，返回的居然是200! RESTful的好處就是可以通過瀏覽器調用服務，把Url貼到瀏覽器中一看，原來返回的居然是LogOn視圖...心中大概有數了，敢情MVC這傢伙自做聰明，直接把401交給了Authentication Module去執行Unauthorized Handler了，整個過程類似在使用Authorize特性時使用者沒有登入一樣(因為實際上在執行Authorization Filter時，也是通過HttpUnauthorizedResult執行個體將Response的StatusCode設定為401)。可是我現在使用的是用戶端調用Web Service，你給我一個登入介面有啥用呢？再說了，我只是沒有許可權訪問某個服務方法(Action)，又不是沒有登入，難道讓我使用403去代替401嗎？但這不是我想要的，經過一番尋找，發現在HttpApplication.EndRequest事件貌似可以，MSDN描述如下：“在 ASP.NET 響應請求時作為 HTTP 執行管線鏈中的最後一個事件發生”，最後一個事件應該是過了Authentication Module了吧，但是總覺得把這麼一個事情放在Application中去處理，似乎有點太“重”了，憑什麼其他的錯誤碼都可以作為ActionResult來處理，而一個401就能那麼特殊呢，再說了，老衲一向痛恨“權貴”...再一找，又發現一個解決方案，HttpResponseBase.End 方法,MSDN描述如下：“在衍生類別中重寫時，將當前緩衝的所有輸出發送至用戶端，停止執行請求的進程，並引發 EndRequest 事件”，換句話說，EndRequest就是End方法發出來了；而且在此之前“停止執行請求的進程”，這樣Authentication Module就沒有機會執行了，這樣應該也不用去LogOn的Action了，哈哈，趕緊測試：

            this.HttpContext.Response.Clear();            this.HttpContext.Response.StatusCode = 401;            this.HttpContext.Response.End();            return new EmptyResult();

先使用Chrome看下響應代碼

果然，如願得到了401，把代碼做了些相應的改變，放入HttpStatusResult中，測試，用戶端果然得到了401，完成。

最後再提供一句廢話，聽說把web.config中的 <authentication />配置節點去掉的話也能得到期望結果，如果您有興趣可以試試(這不符合我的需求，所以我沒有做測試)。