處理ASP.NET Core中的HTML5客戶端路由回退

在使用由Angular，React，Vue等應用程式框架構建的客戶端應用程式時，您總是會處理HTML5客戶端路由，它將完全在瀏覽器中處理到頁面和組件的客戶端路由。幾乎完全在瀏覽器中...

HTML5客戶端路由在客戶端上工作的很好，但是當深入鏈接到一個站點或在瀏覽器中按刷新時，客戶端路由有一個惡習，變成伺服器HTTP請求。請求可能未配置伺服器的路由。

在這篇文章中，我將討論如何使ASP.NET Core（或間接ASP.NET應用程式）通過有效地將客戶端應用程式重新連接到其路由來處理這些“假”請求。

Html 5客戶端路由？

如果您不知道HTML5客戶端路由是什麼，請快速回顧一下。

客戶端框架實現他們自己的客戶端路由機制，以便他們可以 - 就像伺服器應用程式 - 在頁面或組件之間進行導航。

Angular支持幾種路由類型：

• 哈希路線（http：// localhost：4200 /＃！/ albums或http：// localhost：4200 /＃/ albums）

• HTML 5路線（http：// localhost：4200 / albums）

#!/ 哈希邦德路線

前者是一種較早的方法，它直接與HTTP語義一起工作，指定任何具有a的URL #在客戶端被觸發並跳轉到頁面內的“本地”URL。框架可以攔截導航並檢查跟隨的URL內容#以確定路線。散列爆炸#!用於區分應用程式URL和普通#錨鏈接。

散列爆炸路線的好處是，他們只是工作。沒有伺服器端出血的路線，如果您書簽或刷新客戶端頁面，它只是如預期的那樣工作，因為散列邏輯是作為瀏覽器中本地URL解析的一部分執行的。很簡單，對吧？它只是工作。

但缺點是，如果您必須手動輸入網址，則這些網址非常難看且不直觀。對於散列爆炸路線來說，這並不是一個很好的論據，但是不管它們是否對HTML5路由不利。

哈希在Angular中的Bang路由

Angular使用預設的HTML5客戶端路由，但它是一個簡單的開關來啟用Hashbang路由，而不是HTML5路由::

// in app.module.tsproviders : [ .. // make sure you use this for Hash Urls rather than HTML 5 routing { provide: LocationStrategy, useClass: HashLocationStrategy },]

只要您routerLink在HTML模板中使用鏈接網址，並router.navigate()在代碼鏈接中使用，Angular交換機就會自動在兩種模式之間進行切換。

• 在HTML中使用<a routerLink="/albums" />鏈接

• 在代碼中使用： router.navigate(["/album",album.id])

HTML5路由

HTML5路由使用更複雜的方法 - 它使用HTML5的Pushstate API來控制客戶端的路由並管理地址欄顯示。

這種方法的優點是，使用HTML5 API相對容易操作，並且使用標準的無延伸路由約定，使用Web應用程式和API時，URL更加簡潔，易於控制。

但是HTML5路由需要伺服器的明確支持來正確理解哪些路由是伺服器路由，哪些是客戶路由。

沒有伺服器處理的HTML5路由問題

問題在於HTML5客戶端路由與伺服器路由無法區分。

http://localhost:4200/albums可以很容易地將客戶端URL作為伺服器端URL。在完全在客戶端上導航時，HTML5路線工作正常 - 應用程式可以攔截導航併在激活特定路線時路由到相應的客戶端頁面。

如果您使用深層鏈接導航到客戶端驅動的應用程式，然後您將該頁面書簽為書簽，然後使用該URL導航回到該頁面，或者刷新當前活動頁面，則會彈出問題。在這兩種情況下，當瀏覽器請求路由時，客戶端應用程式不運行，因此瀏覽器向伺服器請求路由URL。但是，預設情況下不設置處理說/albums路線，所以你會得到一個錯誤。

如果您在ASP.NET Core應用程式中沒有對HTML5路由設置進行任何特殊處理，您將在應用程式中打開錯誤頁面，或者從Kestrel中選擇此預設顯示：

圖1 - 未處理的客戶端路由產生伺服器錯誤

修複伺服器上的客戶端路由

那麼你如何解決這個問題呢？

客戶端SPA應用程式通常有一個或幾個啟動應用程式的靜態頁面。對於一個典型的Angular應用程式，該頁面是index.html啟動應用程式並啟動客戶端路由。大多數框架都足夠聰明，可以在啟動時檢查當前路由，並移至首次訪問請求的路由。

如果客戶端路由從書簽，鏈接或完全刷新被觸發到伺服器，則需要提供index.html並保持原始URL不變。

然後，客戶端應用程式將自行引導，並且內部路由啟動，以希望將您甩回書簽/刷新位置。

從伺服器提供Index.html

為了這個工作，你需要確保伺服器只提供伺服器負責的內容。

有幾種方法可以做到這一點：

• 主機伺服器URL重寫

• 處理ASP.NET Core應用程式中的客戶端路由

主機Web伺服器上的URL重寫

如果您在主流Web伺服器上運行ASP.NET Core（或ASP.NET）應用程式，最簡單且最有效的解決方案是重寫客戶端URL併為index.html給定的URL 提供內容。

在IIS上，您可以使用IIS重寫模塊來執行此操作。我最近在一篇博文中更詳細地介紹了這一點：

• ASP.NET核心應用程式的IIS重寫規則

但是這裡是相關的IIS重寫規則：

<rewrite> <rules> <!-- Make sure you have a <base href="/" /> tag to fix the root path or all relative links will break on rewrite --><rule name="AngularJS-Html5-Routes" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll"> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> <add input="{REQUEST_URI}" pattern="api/" negate="true" /> </conditions> <action type="Rewrite" url="wwwroot/index.html" /> </rule> </rules></rewrite>

您可以從以下任何位置安裝UrlRewrite模塊：

• Microsoft下載網站

• choco install urlrewrite

• Web平臺安裝程式

如果你在Linux上運行Docker和nginX或者Apache，那麼類似的Rewrite選項就可以在那裡使用。

讓ASP.NET Core處理客戶端路由

如前所述，我通常使用像IIS或nginX這樣的前端Web伺服器來處理重定向，但是通常在測試或內部應用程式時，只需要Kestrel直接為應用程式提供服務即可。如果您直接讓Kestrel處理HTTP流量，那麼您需要在ASP.NET Core代碼中處理客戶端路由。

捕獲所有app.Run()處理程式

有很多方法可用，但是我發現了在Startup類的Configure()方法中使用一個非常簡單的後備處理程式來處理客戶端路由的最簡單的方法：

// set up whatever routes you use with UseMvc()// you may not need to set up any routes here// if you only use attribute routes!app.UseMvc(routes =>{ routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}");});//handle client side routesapp.Run( async (context) =>{ context.Response.ContentType = "text/html"; await context.Response.SendFileAsync(Path.Combine(env.WebRootPath,"index.html"));});

關鍵是app.Run()位於路由後的管道末端的中間件處理程式。如果伺服器端路由不能找到匹配的路由，這個通用處理程式就會啟動。

上面的代碼是你可以做的最簡單的事情，只是把內容發送index.html到客戶端。如果您有多個靜態頁面和SPA筒倉，您可以在其中添加額外的邏輯來嘗試確定需要載入哪個頁面。

請註意，內容不會重定向到，而是作為內嵌流發送到現有的URL請求，以便用戶請求的URL保持不變。這確保了當用戶請求http://localhost:4200/albums你回到那個客戶端頁面而不是index.html。

捕獲所有路由處理程式

另一種方法是在路由定義中使用最後定義的全部捕獲的 MVC路由處理程式。這基本上拿起你的MVC路由配置無法處理的任何URL，然後路由到你指定的路線。

使用catch-all處理程式設置您的MVC路線，將此代碼放在您的Startup類的Configure()方法中：

app.UseMvc(routes =>{ // default routes plus any other custom routesroutes.MapRoute(name: "default",template: "{controller=Home}/{action=Index}/{id?}"); // Catch all Route - catches anything not caught be other routesroutes.MapRoute(name: "catch-all",template: "{*url}",defaults: new {controller = "AlbumViewerApi", action = "RedirectIndex"});});

然後執行完全相同的事情中間件處理程式使用：index.html使用以下代碼將內容流式傳輸到客戶端：

// we need hosting environment for base pathpublic IHostingEnvironment HostingEnv { get; }public AlbumViewerApiController(IHostingEnvironment env){ HostingEnv = env;}[HttpGet]public IActionResult RedirectIndex(){ return new PhysicalFileResult( Path.Combine(HostingEnv.WebRootPath,"index.html"), new MediaTypeHeaderValue("text/html") );}

Catch-All Route不使用屬性路由

確保您為回退路線指定的路線不具有分配給它的屬性路線。當我昨天檢查出來的時候，我無法得到一條全面的路線，直到我[Route("api/RedirectIndex")]從控制器的操作中移除 了這個全部工作。

SpaServices

SpaServices提供了另一個選項，routes.MapSpaFallbackRoute()儘管我自己也沒有嘗試過，但是如果您已經在ASP.NET Core應用程式中使用了Spa服務，那麼這可能是一個簡單的方法來實現這個功能，包括潛在的支持伺服器預渲染。

概要

HTML5路由為客戶端應用程式提供了乾凈的URL，但它的價格必須有伺服器支持才能使其工作。使用主機Web伺服器中的重寫規則或直接在Kestrel的中間件管道或自定義路由處理程式中進行設置並不困難，但是您必須確保將此功能顯式添加到您創建的每個ASP.NET應用程式中。

儘管舊的Hash Bang路線看起來不那麼乾凈，但它們工作正常，不需要任何伺服器端支持。對於需要支持古代瀏覽器的非公眾應用程式或應用程式，在沒有伺服器支持的情況下，散列邦線路仍然是提供路由的可行方式。

最後，如果您正在使用完整的Web伺服器，UrlRewriting是處理非ASP.NET內核後端直接處理的非API內容的最乾凈和最有效的方式。

選擇是好的，你有幾個選擇提供方便，乾凈的網址或簡單的只是把它放在功能。你的選擇...