TWI472205B - A system for implementing an HTTP request service and a method thereof - Google Patents

Description

用於實現HTTP請求服務的系統及其方法

本發明涉及WEB應用中的HTTP服務，尤其涉及HTTP服務中的重定向技術。

在現有技術中，如果網路用戶在HTTP用戶端需要訪問某一網頁，在位址欄中輸入該網頁所對應的URL位址後，一般情況下HTTP伺服器就會返回該用戶所需的頁面。然而，在網際網路上有很多網站在建設過程中引入了網頁重定向技術，以使得網路用戶在所訪問的目標網頁遇到網站調整、網頁目錄結構改變、網頁被轉移到新的URL位址、或者網頁副檔名改變時，仍然能夠達到真實的URL內容。在上述情況下，如果沒有重定向功能，則網路用戶的收藏夾或者搜索引擎的資料庫中的舊位址只能讓訪客得到一個404頁面錯誤資訊，導致訪問流量白白喪失。此外，某些網站註冊了多個功能變數名稱，這時也需要通過重定向讓訪問這些功能變數名稱的網路用戶自動跳轉到主站點。

更為具體地，當HTTP伺服器使用標準的HTTP重定向功能時，首先將3XX命令字和重定向的URL一起返回至HTTP用戶端，然後HTTP用戶端接收到返回碼是301、302、303或者307時，根據返回的重定向URL，HTTP用戶端向HTTP服務器重新發起請求，以獲得真實的URL內容。例如，返回碼301表示永久性轉移，返回碼302表示暫時性轉移等等。

由此可知，在當前的標準HTTP重定向功能中，HTTP在獲得真實的URL內容前，首先要接收來自HTTP伺服器的重定向URL，並根據該重定向URL再次向HTTP伺服器發起請求。這樣不僅要花費額外的網路帶寬，尤其是對於像手機上網這樣網路帶寬要求高的場合很不適合，而且因採用流量付費機制，增加了上網用戶的通訊費用。此外，HTTP用戶端需要重新向HTTP伺服器發起URL請求，反應速度也會隨之降低，尤其是在網路環境複雜的Internet和手機上面，用戶體驗感較差。再者，如果HTTP用戶端不支援重定向命令，將會導致向HTTP伺服器重新發送的URL請求失敗。因而，如何為HTTP用戶端的用戶提供迅捷、方便的URL請求服務，是本領域技術人員急需解決的課題之一。

針對現有技術中HTTP服務的重定向應用所存在的上述缺陷，本發明提供了一種實現HTTP請求服務的系統及其方法。採用該系統和方法，當HTTP用戶端向HTTP伺服器發送URL請求後，可以直接獲取所需的真實URL內容，不必由HTTP用戶端再次向HTTP伺服器發送重定向的URL請求，極大地增強了用戶體驗。

根據本發明的一個方面，提供了一種用於實現HTTP請求服務的方法，該方法包括步驟：HTTP用戶端向HTTP服務端發送URL請求；所述HTTP服務端接收和處理該URL請求，並將URL請求或者URL請求返回的處理結果轉發至重定向分析模組；所述重定向分析模組判斷是否需要進行重定向，當確定予以重定向時，所述重定向分析模組向該相應的URL發送請求；和所述HTTP服務端接收來自所述重定向分析模組的真實URL內容，並直接發送至所述HTTP用戶端。

其中，當需要重定向時，所述重定向分析模組向重定向的URL發送請求，返回具有HTTP協定頭的結果，並且當所述HTTP協定頭中的命令字為301/302/303/307且具有Location協定頭和相應的URL時，所述重定向分析模組向該相應的URL發送請求；當無需重定向時，所述重定向分析模組將接收的URL請求直接返回至所述HTTP服務端。其中，HTTP服務端和重定向分析模組放置在HTTP伺服器中。

其中，HTTP用戶端接收用戶所期望的真實URL內容與所述HTTP用戶端是否支援重定向功能無關；並且HTTP用戶端接收用戶所期望的真實URL內容與所述重定向分析模組的判斷結果無關。

其中，所述用戶請求的URL與所述重定向分析模組返回的URL對應於不同的HTTP伺服器或者相同的伺服器。

根據本發明的又一個方面，提供了一種用於實現HTTP請求服務的系統，該系統至少包括：HTTP用戶端，用於發送用戶的URL請求；以及HTTP伺服器，用於接收所述HTTP用戶端的URL請求，並直接返回用戶所期望的真實URL內容至所述HTTP用戶端。

其中，HTTP伺服器還包括HTTP服務端和重定向分析模組：所述HTTP服務端接收來自HTTP用戶端的URL請求並進行處理；以及重定向分析模組接收經所述HTTP服務端轉發的URL請求或者URL請求返回的結果並判斷是否需要進行重定向。

其中，重定向分析模組確定需要重定向時，向重定向的URL發送請求，並返回具有HTTP協定頭的結果；以及當所述HTTP協定頭中的命令字為301/302/303/307並具有Location協定頭和相應的URL時，所述重定向分析模組向該相應的URL發送請求。

其中，重定向分析模組將真實URL內容返回至HTTP服務端。

其中，HTTP用戶端接收用戶所期望的真實URL內容與所述HTTP用戶端是否支援重定向功能無關；並且HTTP用戶端接收用戶所期望的真實URL內容與所述重定向分析模組的判斷結果無關。

其中，所述用戶請求的URL與所述重定向分析模組返回的URL對應於不同的HTTP伺服器或者相同的HTTP伺服器。

採用本發明中用於實現HTTP請求服務的系統和方法，用戶只需發送原始的URL請求就可以獲取與該URL請求相對應的真實URL內容，更節省網路帶寬，更節約成本；而且，極大地減少了HTTP用戶端向HTTP伺服器發送URL請求的數目，降低了HTTP伺服器的連接負擔。與此同時，採用了HTTP伺服器中的重定向分析模組後，HTTP用戶端不再取決於是否支援重定向功能，而且反應速度更快，用戶體驗感更好。

下面參照附圖，對本發明的具體實施方式作進一步的詳細描述。

圖1示出了現有技術中HTTP用戶端向HTTP伺服器發送URL請求的原理方塊圖。如圖1所示，整個系統包括HTTP用戶端100，HTTP伺服器端A102，HTTP伺服器端B106、目的URL內容104和真實URL內容108。本領域的技術人員應當理解，從技術實現的角度來看，HTTP伺服器端A102和HTTP伺服器端B106可以屬於同一個伺服器，也可以分屬於不同的伺服器，它們均可以用於接收來自HTTP用戶端100的URL請求。

例如，HTTP用戶端100需要訪問某一網頁，並在瀏覽器的位址欄中輸入http://www.alisoft.com/im/gettip.html後，瀏覽器接收該指令，並與HTTP伺服器端A102建立連接，此處的HTTP伺服器端A是指www.alisoft.com網站對應的伺服器；然後，HTTP伺服器端A102對於該URL請求進行處理，在處理過程中，由於/im/gettip.html這個URL對應的內容可能被修改了，並且該URL的服務提供商將其暫時性地重定向至http://www.alisoft.com/portal/getnewtip.html，則HTTP伺服器端A102將重定向命令302和重定向的URL返回至HTTP用戶端100，然後HTTP用戶端100接收到重定向命令302以及重定向的URL(即，http://www.alisoft.com/portal/getnewtip.html)，並向HTTP伺服器端B106重新發送URL請求，此處的HTTP伺服器端B也是指www.alisoft.com網站對應的伺服器，該HTTP伺服器端B106對該URL請求進行處理，並將真實URL內容返回給HTTP用戶端100。需要指出的是，目的URL內容104是指HTTP用戶端100發出請求後應返回的內容，該例中是指302http://www.alisoft.com/portal/getnewtip.html；真實URL內容108是指HTTP用戶端100真正應該獲取的內容，在該例中就是重定向URL即http://www.alisoft.com/portal/getnewtip.html所返回的內容。

在上述實施例中，雖然HTTP伺服器端A102和HTTP伺服器端B106同屬於一個伺服器，但是從該方塊圖可以看出，對於HTTP用戶端100來說，從發出URL請求到獲取真實URL內容的過程中，前後需要兩次向HTTP伺服器發送URL請求，一次是用戶所需訪問的原始URL請求，一次是重定向的URL請求。

為了更加明確地說明圖1所示的HTTP用戶端向HTTP伺服器發送URL請求的過程，圖2示出了HTTP用戶端向HTTP伺服器發送URL請求的流程示意圖，它主要包括以下步驟：步驟200，HTTP用戶端100向HTTP伺服器端A102發送URL請求；步驟202，HTTP伺服器端A102接收該URL請求，並進行處理；步驟204，基於目的URL內容，判斷是否需要進行重定向處理；也就是說，如果用戶所需訪問的URL請求被服務商進行了重定向處理，則HTTP伺服器端A102對其進行解析，並獲得重定向命令3XX和重定向的URL；如果無需進行重定向，則HTTP伺服器端A102直接向HTTP用戶端100返回URL內容；步驟206，若進行重定向，HTTP伺服器端A將重定向命令3XX(例如301、302、303或者307等)和重定向URL返回至HTTP用戶端100；步驟208，HTTP用戶端100向HTTP伺服器端B106發送重定向的URL請求；步驟210，HTTP伺服器端B106接收該URL請求並處理；以及步驟212，HTTP伺服器端B106將真實URL內容返回至HTTP用戶端100。

由上述可知，在步驟206中，HTTP用戶端100接收來自HTTP伺服器端A的重定向命令3XX和重定向URL。這就意味著，HTTP用戶端必須支持重定向命令，否則該HTTP用戶端再次向HTTP伺服器端B發送URL請求將會失敗。

圖3示出了本發明中HTTP用戶端向HTTP伺服器發送URL請求的原理方塊圖。如圖3所示，本發明的系統至少包括：HTTP用戶端A40、HTTP伺服器30、目的URL內容50、和真實URL內容60。進一步，該HTTP伺服器30包括HTTP服務端A300和重定向分析模組302。關於目的URL內容和真實URL內容的詳細定義，已經在圖1中予以描述，此處省略。

為便於描述，預設用戶訪問的URL為http://www.alisoft.com/im/gettip.html，並且服務商已經將該URL重定向至http://www.alisoft.com/portal/getnewtip.html。當用戶在HTTP用戶端A40發送URL請求時，HTTP伺服器30通過HTTP服務端A300接收該URL請求，並對其進行處理；然後，HTTP服務端A300將處理的URL結果轉發至重定向分析模組302，由該重定向分析模組302來判斷是否需要進行重定向。如果無需重定向處理，則重定向分析模組302直接返回URL至HTTP服務端A300，並由HTTP服務端A300發送至HTTP用戶端A40；如果需要進行重定向，則重定向分析模組302直接向http://www.alisoft.com/portal/getnewtip.html發起請求並得到結果。當分析結果中的HTTP協定頭返回的命令字為301、302、303或者307，並帶有Location協定頭和對應的URL時，重定向分析模組302向Location指定的URL發送請求，並返回結果至HTTP服務端A300。接著，該HTTP服務端A300將真實URL內容發送至HTTP用戶端A40，以實現用戶所需的HTTP請求服務。

圖4示出了如圖3所示的HTTP用戶端向HTTP伺服器發送URL請求的流程示意圖。結合圖4，本領域的技術人員能夠更加容易地理解本發明的HTTP用戶端向HTTP伺服器請求URL的技術實現方案。而且，圖4也能夠清晰地示出HTTP用戶端A40、HTTP服務端A300、以及重定向分析模組302之間的交互過程。該方法主要包括以下步驟：步驟400，HTTP用戶端A40向HTTP服務端A300發送原始URL請求；步驟402，HTTP服務端A接收和處理該URL請求，並獲得處理結果；步驟404，HTTP服務端A將該處理結果轉發至重定向分析模組302；步驟406，通過重定向分析模組302來判斷該URL是否需要進行重定向。如果重定向，則跳轉至步驟408；如果無需重定向，則跳轉至步驟410；步驟408，當確定要重定向時，由該重定向分析模組302直接向真實的URL發送請求，並對返回的結果進行處理。更為具體地，重定向分析模組302分析所返回結果的HTTP協定頭，如協定頭中返回的命令字是3XX，並具有Location協定頭和相應的URL，則該分析模組向Location指定的相應URL發出請求；步驟410，返回真實URL內容至HTTP服務端A並進行處理；以及步驟412，HTTP服務端A將真實URL內容返回至HTTP用戶端A40。

進一步，在步驟404中，如果用戶發起的URL請求沒有經過重定向處理，則HTTP服務端A經過處理後仍然將該URL請求轉發至重定向分析模組；如果用戶發起的URL請求已經被服務商進行了重定向處理，則HTTP服務端A處理URL請求，並將該URL請求返回的結果轉發至重定向分析模組，這裏URL請求返回的結果是指用戶的原始URL請求所對應的目的URL內容。例如，在本實施例中，用戶的原始URL請求為http://www.alisoft.com/im/gettip.html，那麼HTTP服務端A對該URL請求進行處理的返回結果是302http://www.alisoft.com/portal/getnewtip.html。換句話說，無論用戶的原始URL請求是否需要進行重定向處理，HTTP服務端A都將該URL請求的處理結果轉發至重定向分析模組，其中，需要進行重定向的情況下，該處理結果為處理URL請求而返回的結果；無需進行重定向的情況下，該處理結果為原始URL請求。

由本發明的上述實現步驟可以知曉，當用戶需要訪問URL並向HTTP伺服器30發送該URL請求時，在HTTP伺服器30專門設置有一重定向分析模組302對其進行重定向判斷，並且無論是否需要重定向，HTTP用戶端A40所獲得的均為原始URL請求的真實URL內容。只是需要指出，當重定向分析模組302判斷為重定向時，該分析模組需要向真實URL發送請求，並進行一系列的處理後將真實URL內容返回至HTTP服務端A。

圖1和圖2示出了現有技術中HTTP用戶端向HTTP伺服器發送URL請求的原理方塊圖和流程示意圖；而圖3和圖4示出了本發明中HTTP用戶端向HTTP伺服器發送URL請求的原理方塊圖和流程示意圖。以下，針對現有技術和本發明中HTTP用戶端向HTTP伺服器發送URL請求時的不同，圖5示出了該申請與現有技術在HTTP請求服務的實現方案的比較示意圖。其中，圖5A示出了現有技術中HTTP用戶端從發送URL請求到返回真實URL內容的進程示意圖；圖5B示出了本發明中HTTP用戶端從發送URL請求到返回真實URL內容的進程示意圖。

參照圖5A，在HTTP用戶端A100、HTTP服務端A102和HTTP服務端B106的交互關係中，首先，HTTP用戶端A100向HTTP服務端A102發送URL請求，並由HTTP服務端A100返回重定向的命令和重定向URL至HTTP用戶端A100；然後，由HTTP用戶端A100向HTTP服務端B106發送重定向的URL請求，並有HTTP服務端B106將真實URL內容返回至HTTP用戶端A100。不難看出，無論HTTP服務端A102和HTTP服務端B106是否屬於同一伺服器，HTTP用戶端A100均需要向HTTP服務端發送兩次URL請求，無形之中，需要花費額外的網路帶寬，而且用戶的體驗感相對較差。

參照圖5B，在HTTP用戶端A40和HTTP服務端A300的交互關係中，HTTP用戶端A40向HTTP服務端A300發送原始URL請求，無論該URL請求是否由服務商重定向到另一新的URL，HTTP服務端A300均直接向HTTP用戶端A40返回真實URL內容。與圖5A相比，位於HTTP用戶端A40的用戶體驗感較好，因為從某種意義上來說，用戶只關心通過原始URL請求所獲得的真實URL內容，而無需關注是否先返回重定向命令和重定向URL，然後根據該重定向命令和重定向URL向HTTP服務端發送URL請求以得到真實URL內容。

再次結合圖5A和圖5B，雖然圖5B中的HTTP服務端A利用重定向分析模組302來對重定向進行處理，但是，從HTTP用戶端A40來看，用戶只需發送URL請求就能夠獲取與該URL請求相對應的真實URL內容，這樣就使得HTTP用戶端與HTTP伺服器之間的交互更為友好，更節省網路帶寬；而且從HTTP伺服器30來看，極大地減少了HTTP用戶端向HTTP伺服器發送的URL請求數目。

上文中，參照附圖描述了本發明的具體實施方式。但是，本領域中的普通技術人員能夠理解，在不偏離本發明的精神和範圍的情況下，還可以對本發明的具體實施方式作各種變更和替換。這些變更和替換都落在本發明申請專利範圍所限定的範圍內。

30．．．HTTP伺服器

40．．．HTTP用戶端A

50．．．目的URL內容

60．．．真實URL內容

100．．．HTTP用戶端

102．．．HTTP伺服器端A

104．．．目的URL內容

106．．．HTTP伺服器端B

108．．．真實URL內容

300．．．HTTP服務端A

302．．．重定向分析模組

讀者在參照附圖閱讀了本發明的具體實施方式以後，將會更清楚地瞭解本發明的各個方面。其中，

圖1示出了現有技術中HTTP用戶端向HTTP伺服器發送URL請求的原理方塊圖；

圖2示出了圖1所示的HTTP用戶端向HTTP伺服器發送URL請求的流程示意圖；

圖3示出了本發明中HTTP用戶端向HTTP伺服器發送URL請求的原理方塊圖；

圖4示出了圖3所示的HTTP用戶端向HTTP伺服器發送URL請求的流程示意圖；以及

圖5示出了現有技術與本發明申請的HTTP用戶端向HTTP伺服器發送URL請求的比較示意圖，其中圖5A示出了現有技術中HTTP用戶端從發送URL請求到返回真實URL內容的進程示意圖；和圖5B示出了本發明中HTTP用戶端從發送URL請求到返回真實URL內容的進程示意圖。

30．．．HTTP伺服器

40．．．HTTP用戶端A

50．．．目的URL內容

60．．．真實URL內容

300．．．HTTP服務端A

302．．．重定向分析模組

Claims (14)

1. 一種用於實現HTTP請求服務的系統，其特徵在於，該系統至少包括：HTTP用戶端，用於發送用戶的URL請求；以及HTTP伺服器，用於接收該HTTP用戶端的URL請求，並直接返回用戶所期望的真實URL內容至該HTTP用戶端，其中，該HTTP伺服器還包括HTTP服務端和重定向分析模組，其中，該HTTP服務端接收來自HTTP用戶端的URL請求並進行處理；以及該重定向分析模組接收該HTTP服務端的處理結果並判斷是否需要進行重定向，其中，當確定需要進行重定向時，該重定向分析模組向重定向的URL發送請求，然後經由該HTTP服務端直接將真實URL內容返回至該HTTP用戶端。
2. 如申請專利範圍第1項之系統，其中，該重定向分析模組確定需要重定向時，向重定向的URL發送請求，並返回具有HTTP協定頭的結果；以及當該HTTP協定頭中的命令字為301/302/303/307並具有Location協定頭和相應的URL時，該重定向分析模組向該相應的URL發送請求。
3. 如申請專利範圍第1項之系統，其中，該HTTP用戶端接收用戶所期望的真實URL內容與該HTTP用戶端是否支援重定向功能無關。
4. 如申請專利範圍第1項之系統，其中，該HTTP 用戶端接收用戶所期望的真實URL內容與該重定向分析模組的判斷結果無關。
5. 如申請專利範圍第1項之系統，其中，該用戶請求的URL與該重定向分析模組返回的URL對應於不同的HTTP伺服器。
6. 如申請專利範圍第1項之系統，其中，該用戶請求的URL與該重定向分析模組返回的URL對應於相同的HTTP伺服器。
7. 一種用於實現HTTP請求服務的方法，其特徵在於，該方法包括步驟：HTTP用戶端向HTTP服務端發送URL請求；該HTTP服務端接收和處理該URL請求，並將處理結果轉發至重定向分析模組；該重定向分析模組判斷是否需要進行重定向，當確定予以重定向時，該重定向分析模組向該相應的URL發送請求；和該HTTP服務端接收來自該重定向分析模組的真實URL內容，並直接發送至該HTTP用戶端。
8. 如申請專利範圍第7項之方法，其中，當需要重定向時，該重定向分析模組向重定向的URL發送請求，並返回具有HTTP協定頭的結果；並且當該HTTP協定頭中的命令字為301/302/303/307且具有Location協定頭和相應的URL時，該重定向分析模組向該相應的URL發送請求。
9. 如申請專利範圍第7項之方法，其中，當無需重定向時，該重定向分析模組將接收的URL請求直接返回至該HTTP服務端。
10. 如申請專利範圍第7項之方法，其中，該HTTP服務端和該重定向分析模組放置在HTTP伺服器中。
11. 如申請專利範圍第7項之方法，其中，該HTTP用戶端接收用戶所期望的真實URL內容與該HTTP用戶端是否支援重定向功能無關。
12. 如申請專利範圍第7項之方法，其中，該HTTP用戶端接收用戶所期望的真實URL內容與該重定向分析模組的判斷結果無關。
13. 如申請專利範圍第7項之方法，其中，該用戶請求的URL與該重定向分析模組返回的URL對應於不同的HTTP伺服器。
14. 如申請專利範圍第7項之方法，其中，該用戶請求的URL與該重定向分析模組返回的URL對應於相同的HTTP伺服器。