TW201039591A - System and method for realizing HTTP request service - Google Patents

System and method for realizing HTTP request service Download PDF

Info

Publication number
TW201039591A
TW201039591A TW98114032A TW98114032A TW201039591A TW 201039591 A TW201039591 A TW 201039591A TW 98114032 A TW98114032 A TW 98114032A TW 98114032 A TW98114032 A TW 98114032A TW 201039591 A TW201039591 A TW 201039591A
Authority
TW
Taiwan
Prior art keywords
http
url
request
analysis module
http server
Prior art date
Application number
TW98114032A
Other languages
Chinese (zh)
Other versions
TWI472205B (en
Inventor
jian-xiang Mo
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to TW98114032A priority Critical patent/TWI472205B/en
Publication of TW201039591A publication Critical patent/TW201039591A/en
Application granted granted Critical
Publication of TWI472205B publication Critical patent/TWI472205B/en

Links

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

The present invention discloses a system for realizing HTTP request service, which comprises HTTP user end for sending URL requests, and HTTP server for receiving URL requests and directly returning real URL content. The present invention also discloses a method for achieving the above system, including: HTTP user end sends URL requests to the HTTP service end; HTTP service end forwards the URL requests or the processed results that URL requests to return to redirection analysis module; determine redirection or not, and when redirection is ascertained, redirection analysis module sends a request to the redirected URL and returns the real URL content to the HTTP user end. Adopting the system and method in this invention, users can directly access real URL content relevant to the URL request. The bandwidth is saved and the number of URL requests associated with HTTP server is greatly reduced, thereby reducing the burden of HTTP server.

Description

201039591 六、發明說明 【發明所屬之技術領域】 本發明涉及WEB應用中的HTTP服務,尤其涉及 HTTP服務中的重定向技術。 【先前技術】 在現有技術中,如果網路用戶在HTTP用戶端需要訪 問某一網頁,在位址欄中輸入該網頁所對應的URL位址 後,一般情況下HTTP伺服器就會返回該用戶所需的頁 面。然而,在網際網路上有很多網站在建設過程中引入了 網頁重定向技術,以使得網路用戶在所訪問的目標網頁遇 到網站調整、網頁目錄結構改變、網頁被轉移到新的URL 位址、或者網頁副檔名改變時,仍然能夠達到真實的URL 內容。在上述情況下,如果沒有重定向功能,則網路用戶 的收藏夾或者搜索引擎的資料庫中的舊位址只能讓訪客得 到一個404頁面錯誤資訊,導致訪問流量白白喪失。此 外,某些網站註冊了多個功能變數名稱,這時也需要通過 重定向讓訪問這些功能變數名稱的網路用戶自動跳轉到主 站點。 更爲具體地,當HTTP伺服器使用標準的HTTP重定 向功能時,首先將3XX命令字和重定向的URL —起返回 至HTTP用戶端,然後HTTP用戶端接收到返回碼是 301、302、303或者307時,根據返回的重定向URL, HTTP用戶端向HTTP服務器重新發起請求,以獲得真實 201039591 的URL內容。例如,返回碼301表示永久性轉移,返回 碼3 02表示暫時性轉移等等。 由此可知’在當前的標準 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請求,極大地增強了用戶體驗。201039591 VI. Description of the Invention [Technical Field] The present invention relates to an HTTP service in a WEB application, and more particularly to a redirection technology in an HTTP service. [Prior Art] In the prior art, if a network user needs to access a certain webpage on the HTTP client, and enters the URL address corresponding to the webpage in the address bar, the HTTP server generally returns the user. The page you need. However, many websites on the Internet have introduced webpage redirection technology during the construction process, so that web users encounter website adjustments, webpage directory structure changes, and webpages are transferred to new URL addresses. Or, when the page extension is changed, the actual URL content can still be reached. In the above case, if there is no redirection function, the network user's favorites or the old address in the search engine's database can only give the visitor a 404 page error message, resulting in the loss of access traffic. In addition, some websites register multiple function variable names, and it is also necessary to redirect the network users who access these function variable names to the main site through redirection. More specifically, when the HTTP server uses the standard HTTP redirection function, the 3XX command word and the redirected URL are first returned to the HTTP client, and then the HTTP client receives the return code of 301, 302, 303. Or at 307, according to the returned redirect URL, the HTTP client re-initiates the request to the HTTP server to obtain the URL content of the real 201039591. For example, return code 301 indicates a permanent transfer, return code 032 indicates a temporary transfer, and the like. It can be seen that in the current standard HTTP redirect function, HTTP first receives the redirect URL from the HTTP server before obtaining the real URL content, and then initiates a request to the HTTP server again according to the redirect URL. This not only requires additional network bandwidth, especially for situations where the network bandwidth requirements such as mobile Internet access are high, and the use of the traffic payment mechanism increases the communication cost of Internet users. In addition, the HTTP client needs to re-initiate the URL request to the HTTP server, and the response speed will also decrease, especially in the Internet and mobile phones with complex network environments. Furthermore, if the HTTP client does not support the redirect command, it will cause the URL request resent to the HTTP server to fail. Therefore, how to provide a quick and convenient URL request service for the user of the HTTP client is one of the urgent problems to be solved by those skilled in the art. SUMMARY OF THE INVENTION In view of the above drawbacks of the redirection application of the HTTP service in the prior art, the present invention provides a system for implementing an HTTP request service and a method thereof. With the system and method, when the HTTP client sends a URL request to the HTTP server, the desired real URL content can be directly obtained. 'The HTTP client does not have to send the redirected URL request to the HTTP server again, which greatly enhances the request. user experience.

根據本發明的一個方面,提供了 一種用於實現HTTP -6- 201039591 請求服務的方法,該方法包括步驟: HTTP用戶端向HTTP服務端發送URL請求; 所述HTTP服務端接收和處理該URL請求,並將 URL請求或者URL請求返回的處理結果轉發至重定向分 析模組; 所述重定向分析模組判斷是否需要進行重定向,當確 定予以重定向時,所述重定向分析模組向該相應的URL 發送請求;和 所述HTTP服務端接收來自所述重定向分析模組的真 實URL內容,並直接發送至所述HTTP用戶端。 其中,當需要重定向時,所述重定向分析模組向重定 向的URL發送請求,返回具有HTTP協定頭的結果,並 且當所述HTTP協定頭中的命令字爲3 0 1 /3 02/3 03/3 07且 具有Location協定頭和相應的URL時,所述重定向分析 模組向該相應的URL發送請求;當無需重定向時,所述 重定向分析模組將接收的URL請求直接返回至所述HTTP 服務端。其中,HTTP服務端和重定向分析模組放置在 HTTP伺服器中。 其中,HTTP用戶端接收用戶所期望的真實URL內容 與所述HTTP用戶端是否支援重定向功能無關;並且 HTTP用戶端接收用戶所期望的真實URL內容與所述重定 向分析模組的判斷結果無關。 其中,所述用戶請求的URL與所述重定向分析模組 返回的URL對應於不同的HTTP伺服器或者相同的伺服 201039591 器。 根據本發明的又一個方面,提供了一種用於實現 HTTP請求服務的系統,該系統至少包括: HTTP用戶端,用於發送用戶的URL請求;以及 HTTP伺服器’用於接收所述HTTP用戶端的URL請 求,並直接返回用戶所期望的真實URL內容至所述HTTP 用戶端。According to an aspect of the present invention, a method for implementing an HTTP -6-201039591 request service is provided, the method comprising the steps of: an HTTP client transmitting a URL request to an HTTP server; the HTTP server receiving and processing the URL request And forwarding the processing result returned by the URL request or the URL request to the redirection analysis module; the redirection analysis module determines whether redirection is required, and when determining to redirect, the redirection analysis module is Corresponding URL sends a request; and the HTTP server receives the real URL content from the redirect analysis module and sends the content directly to the HTTP client. Wherein, when redirection is required, the redirection analysis module sends a request to the redirected URL, returns a result with an HTTP protocol header, and when the command word in the HTTP protocol header is 3 0 1 /3 02/ 3 03/3 07 and having a Location Agreement header and a corresponding URL, the redirect analysis module sends a request to the corresponding URL; when no redirection is required, the redirect analysis module will directly receive the URL request Return to the HTTP server. The HTTP server and the redirect analysis module are placed in the HTTP server. The HTTP client receives the real URL content expected by the user regardless of whether the HTTP client supports the redirection function; and the HTTP client receives the real URL content expected by the user, and the judgment result of the redirection analysis module is irrelevant. . The URL requested by the user and the URL returned by the redirect analysis module correspond to different HTTP servers or the same server 201039591. According to still another aspect of the present invention, a system for implementing an HTTP request service is provided, the system comprising at least: an HTTP client for transmitting a URL request of a user; and an HTTP server 'for receiving the HTTP client The URL requests and directly returns the actual URL content desired by the user to the HTTP client.

其中,HTTP伺服器還包括HTTP服務端和重定向分 析模組:所述HTTP服務端接收來自HTTP用戶端的URL 請求並進行處理;以及重定向分析模組接收經所述HTTP 服務端轉發的URL請求或者URL請求返回的結果並判斷 是否需要進行重定向。 其中,重定向分析模組確定需要重定向時,向重定向 的URL發送請求,並返回具有HTTP協定頭的結果;以 及當所述HTTP協定頭中的命令字爲30 1 /3 02/303/3 07並 具有Location協定頭和相應的URL時,所述重定向分析 模組向該相應的URL發送請求。 其中,重定向分析模組將真實URL內容返回至HTTP 服務端。 其中,HTTP用戶端接收用戶所期望的真實URL內容 與所述HTTP用戶端是否支援重定向功能無關;並且 HTTP用戶端接收用戶所期望的真實URL內容與所述重定 向分析模組的判斷結果無關。 其中,所述用戶請求的URL與所述重定向分析模組 -8- 201039591 返回的URL對應於不同的HTTP伺服器或者相同的http 伺服器。 採用本發明中用於實現HTTP請求服務的系統和方 法,用戶只需發送原始的URL請求就可以獲取與該URL 請求相對應的真實URL內容,更節省網路帶寬,更節約 成本;而且,極大地減少了 HTTP用戶端向HTTP伺服器 發送URL請求的數目’降低了 HTTP伺服器的連接負 0 擔。與此同時,採用了 HTTP伺服器中的重定向分析模組 後,HTTP用戶端不再取決於是否支援重定向功能,而且 反應速度更快,用戶體驗感更好。 【實施方式】 下面參照附圖,對本發明的具體實施方式作進一步的 詳細描述。 圖1示出了現有技術中HTTP用戶端向HTTP伺服器 ❹ 發送URL請求的原理方塊圖。如圖1所示,整個系統包 括HTTP用戶端100,HTTP伺服器端A102,HTTP伺服 器端B106、目的URL內容104和真實URL內容1〇8。本 領域的技術人員應當理解,從技術實現的角度來看, HTTP伺服器端A102和HTTP伺服器端B106可以屬於同 一個伺服器,也可以分屬於不同的伺服器,它們均可以用 於接收來自HTTP用戶端100的URL請求。 例如,HTTP用戶端100需要訪問某一網頁,並在瀏 覽器的位址欄中輸入 -9 - 201039591 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將重定向命令3 02和重定向的URL 返回至HTTP用戶端100,然後HTTP用戶端100接收到 重定向命令 3 02 以及重定向的 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發出請求後應返 回的內容,該例中是指 3 02http ://ww w alis 〇ft · c〇m/portal/getne wtip ·html ;真實 URL內容108是指HTTP用戶端100真正應該獲取的內 容,在該例中就是重定向URL即 http://www.alisoft.com/portal/getnewtip.html 戶斤返回的內 容。 在上述實施例中,雖然HTTP伺服器端A1 02和HTTP 伺服器端B106同屬於一個伺服器,但是從該方塊圖可以 -10- 201039591 看出’對於HTTP用戶端100來說,從發出URL請求到 獲取真實URL內容的過程中,前後需要兩次向HTTP伺 服器發送URL請求,一次是用戶所需訪問的原始URL請 求’一次是重定向的URL請求。 爲了更加明確地說明圖1所示的HTTP用戶端向 HTTP伺服器發送URL請求的過程,圖2示出了 HTTP用 戶端向HTTP伺服器發送URL請求的流程示意圖,它主 0 要包括以下步驟: 步驟20 0,HTTP用戶端100向HTTP伺服器端A102 發送URL請求; 步驟202,HTTP伺服器端A102接收該URL請求, 並進行處理; 步驟204,基於目的URL內容,判斷是否需要進行重 定向處理;也就是說,如果用戶所需訪問的URL請求被 服務商進行了重定向處理,貝(1 HTTP伺服器端A1 02對其 Q 進行解析,並獲得重定向命令3 XX和重定向的URL ;如 果無需進行重定向,則HTTP伺服器端A1 02直接向HTTP 用戶端100返回URL內容; 步驟206,若進行重定向,HTTP伺服器端A將重定 向命令3 XX (例如301、302、303或者307等)和重定向 URL返回至HTTP用戶端100 ; 步驟208,HTTP用戶端100向HTTP伺服器端B106 發送重定向的URL請求; 步驟210’ HTTP伺服器端B106接收該URL請求並 -11 - 201039591 處理;以及 步驟212,HTTP伺服器端B106將真實URL內容返 回至HTTP用戶端100。 由上述可知,在步驟206中,HTTP用戶端1〇〇接收 來自 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服務端A3 00和重定向分析模組302。 關於目的URL內容和真實URL內容的詳細定義,已經在 圖1中予以描述,此處省略。 爲便於描述,預設用戶訪問的URL爲 http://www. ali soft, com/im/gettip.html > 並且服務商已經 將該URL重定向至 h 11 p : / / w w w. a 1 i s 〇 f t · c 〇 m / ρ 〇 r t a 1 / g e t n e w t i p · h t m 1。當用戶在 HTTP用戶端A40發送URL請求時,HTTP伺服器30通 過HTTP服務端A300接收該URL請求,並對其進行處 理;然後,HTTP服務端A3 00將處理的URL結果轉發至 重定向分析模組3 02,由該重定向分析模組3 02來判斷是 否需要進行重定向。如果無需重定向處理,則重定向分析 -12- 201039591 模組3 02直接返回 URL至HTTP服務端 A3 00,並由 HTTP服務端A3 00發送至HTTP用戶端A40 ;如果需要進 行重定向,則重定向分析模組 302 直接向 http://www.alisoft.com/portal/getnewtip.html 發起請求並 得到結果。當分析結果中的HTTP協定頭返回的命令字爲 301、302、303或者307,並帶有Location協定頭和對應 的URL時,重定向分析模組302向Location指定的URL Q 發送請求,並返回結果至HTTP服務端A3 00。接著,該 HTTP服務端A300將真實URL內容發送至HTTP用戶端 A40,以實現用戶所需的HTTP請求服務。 圖4示出了如圖3所示的HTTP用戶端向HTTP伺服 器發送URL請求的流程示意圖。結合圖4,本領域的技術 人員能夠更加容易地理解本發明的HTTP用戶端向HTTP 伺服器請求URL的技術實現方案。而且,圖4也能夠清 晰地示出HTTP用戶端A40、HTTP服務端A3 00、以及重 Q 定向分析模組3 02之間的交互過程。該方法主要包括以下 ,私 EES^ * w m · 步驟400,HTTP用戶端A40向HTTP服務端A3 00發 送原始URL請求; 步驟402,HTTP服務端A接收和處理該URL請求, 並獲得處理結果; 步驟404,HTTP服務端A將該處理結果轉發至重定 向分析模組3 0 2 ; 步驟406,通過重定向分析模組302來判斷該URL是 -13- 201039591 否需要進行重定向。如果重定向’則跳轉至步驟4 0 8 ;如 果無需重定向,則跳轉至步驟410; 步驟408,當確定要重定向時,由該重定向分析模組 3〇2直接向真實的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 請求進行處理的返回結果是 3 02http://www.alisoft.com/portal/getnewtip.html。換句話 說’無論用戶的原始URL請求是否需要進行重定向處 201039591 理,HTTP服務端A都將該URL請求的處理結果轉發至重 定向分析模組,其中,需要進行重定向的情況下,該處理 結果爲處理URL請求而返回的結果;無需進行重定向的 情況下,該處理結果爲原始URL請求。 由本發明的上述實現步驟可以知曉,當用戶需要訪問 URL並向HTTP伺服器30發送該URL請求時,在HTTP 伺服器30專門設置有一重定向分析模組3 02對其進行重 0 定向判斷,並且無論是否需要重定向,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內容的進程示意圖。The HTTP server further includes an HTTP server and a redirection analysis module: the HTTP server receives the URL request from the HTTP client and processes the same; and the redirect analysis module receives the URL request forwarded by the HTTP server Or the result of the URL request and determine if a redirect is needed. The redirect analysis module determines that a redirect is needed, sends a request to the redirected URL, and returns a result with an HTTP protocol header; and when the command word in the HTTP protocol header is 30 1 /3 02/303/ When the 3 07 has a Location Agreement header and a corresponding URL, the redirect analysis module sends a request to the corresponding URL. The redirect analysis module returns the real URL content to the HTTP server. The HTTP client receives the real URL content expected by the user regardless of whether the HTTP client supports the redirection function; and the HTTP client receives the real URL content expected by the user, and the judgment result of the redirection analysis module is irrelevant. . The URL requested by the user and the URL returned by the redirect analysis module -8-201039591 correspond to different HTTP servers or the same http server. By adopting the system and method for implementing the HTTP request service in the present invention, the user only needs to send the original URL request to obtain the real URL content corresponding to the URL request, thereby saving network bandwidth and saving cost; The number of URL requests sent by the HTTP client to the HTTP server is reduced, which reduces the negative load on the HTTP server. At the same time, after adopting the redirection analysis module in the HTTP server, the HTTP client no longer depends on whether or not the redirection function is supported, and the response speed is faster and the user experience is better. [Embodiment] Hereinafter, embodiments of the present invention will be further described in detail with reference to the accompanying drawings. FIG. 1 is a block diagram showing the principle in which a HTTP client sends a URL request to an HTTP server in the prior art. As shown in Fig. 1, the entire system includes an HTTP client 100, an HTTP server A 102, an HTTP server B 106, a destination URL content 104, and a real URL content 1〇8. Those skilled in the art should understand that from the perspective of technical implementation, the HTTP server A 102 and the HTTP server B 106 may belong to the same server, or may belong to different servers, and they may all be used to receive from URL request for HTTP client 100. For example, the HTTP client 100 needs to access a certain webpage, and after entering -9 - 201039591 http://www.alisoft.com/im/gettip.html in the address bar of the browser, the browser receives the instruction. And establish a connection with the HTTP server A102. Here, the HTTP server A refers to the server corresponding to the website www.alisoft.com; then, the HTTP server A102 processes the URL request, during processing, Since the content corresponding to the /im/gettip.html URL may have been modified, and the service provider of the URL temporarily redirects it to http://www.alisoft.com/portal/getnewtip.html' The HTTP server A 102 returns the redirect command 032 and the redirected URL to the HTTP client 100, and then the HTTP client 100 receives the redirect command 032 and the redirected URL (ie, http://www. Alisoft.com/portal/getnewtip.html ) and resend the URL request to the HTTP server B106. Here, the HTTP server B also refers to the server corresponding to the www.alisoft.com website. The HTTP server B106 Process the URL request and return the actual URL content to H TTP client 100. It should be noted that the destination URL content 104 refers to the content that should be returned after the HTTP client 100 sends a request, in this example, 3 02http ://ww w alis 〇ft · c〇m/portal/getne wtip · html; The real URL content 108 refers to the content that the HTTP client 100 should actually obtain. In this example, the redirect URL is http://www.alisoft.com/portal/getnewtip.html. In the above embodiment, although the HTTP server A1 02 and the HTTP server B 106 belong to the same server, it can be seen from the block diagram -10- 201039591 'For the HTTP client 100, the request is issued from the URL. In the process of obtaining the real URL content, it is necessary to send the URL request to the HTTP server twice before and after, and once is the original URL request that the user needs to access 'one time is the redirected URL request. In order to more clearly explain the process of the HTTP client sending a URL request to the HTTP server shown in FIG. 1, FIG. 2 is a schematic flowchart of the HTTP client sending a URL request to the HTTP server, and the main 0 includes the following steps: Step 20: The HTTP client 100 sends a URL request to the HTTP server A102. In step 202, the HTTP server A102 receives the URL request and performs processing. Step 204: Based on the content of the destination URL, determine whether the redirect processing is required. That is, if the URL request that the user needs to access is redirected by the service provider, the HTTP server A1 02 parses the Q and obtains the redirect command 3 XX and the redirected URL; If no redirection is required, the HTTP server A1 02 directly returns the URL content to the HTTP client 100; Step 206, if redirected, the HTTP server A will redirect the command 3 XX (eg, 301, 302, 303 or 307, etc.) and the redirect URL is returned to the HTTP client 100; in step 208, the HTTP client 100 sends a redirected URL request to the HTTP server B106; Step 210' HTTP server B106 The URL request and -11 - 201039591 processing; and step 212, the HTTP server side B 106 returns the real URL content to the HTTP client 100. As can be seen from the above, in step 206, the HTTP client 1 receives the HTTP server from the HTTP server. End A redirects the command 3XX and redirects the URL. This means that the HTTP client must support the redirect command, otherwise the HTTP client will fail to send the URL request to the HTTP server B again. Figure 3 shows In the present invention, the HTTP client sends a URL request to the HTTP server. As shown in FIG. 3, the system of the present invention at least includes: an HTTP client A40, an HTTP server 30, a destination URL content 50, and a real URL content. 60. Further, the HTTP server 30 includes an HTTP server A3 00 and a redirect analysis module 302. A detailed definition of the destination URL content and the real URL content has been described in FIG. 1 and is omitted here. The default user access URL is http://www.ali soft, com/im/gettip.html > and the service provider has redirected the URL to h 11 p : / / ww w. a 1 is 〇ft · c 〇m / Square r t a 1 / g e t n e w t i p · h t m 1. When the user sends a URL request at the HTTP client A40, the HTTP server 30 receives the URL request through the HTTP server A300 and processes it; then, the HTTP server A3 00 forwards the processed URL result to the redirect analysis module. The group 3 02 is determined by the redirection analysis module 302 to determine whether redirection is required. If no redirection processing is required, the redirection analysis -12-201039591 module 3 02 directly returns the URL to the HTTP server A3 00 and is sent by the HTTP server A3 00 to the HTTP client A40; if redirection is required, the redirection analysis Module 302 initiates a request directly to http://www.alisoft.com/portal/getnewtip.html and obtains the results. When the command word returned by the HTTP protocol header in the analysis result is 301, 302, 303 or 307 with the Location contract header and the corresponding URL, the redirect analysis module 302 sends a request to the URL Q specified by the Location, and returns The result is to the HTTP server A3 00. Next, the HTTP server A300 sends the real URL content to the HTTP client A40 to implement the HTTP request service required by the user. FIG. 4 is a flow chart showing the process of sending a URL request to an HTTP server by an HTTP client as shown in FIG. 3. With reference to Figure 4, those skilled in the art can more easily understand the technical implementation of the HTTP client of the present invention requesting a URL from an HTTP server. Moreover, FIG. 4 can also clearly show the interaction process between the HTTP client A40, the HTTP server A3 00, and the re-Q orientation analysis module 302. The method mainly includes the following: private EES^*wm · Step 400, the HTTP client A40 sends an original URL request to the HTTP server A3 00; Step 402, the HTTP server A receives and processes the URL request, and obtains a processing result; 404, the HTTP server A forwards the processing result to the redirect analysis module 3 0 2 ; Step 406, the redirect analysis module 302 determines whether the URL is -13-201039591. If redirected, then go to step 4 0 8; if there is no need to redirect, go to step 410; Step 408, when it is determined to be redirected, the redirect analysis module 3〇2 directly sends a request to the real URL 'Process the returned results. More specifically, the redirect analysis module 302 analyzes the HTTP protocol header of the returned result. If the command word returned in the contract header is 3XX' and has a Location contract header and a corresponding URL, the analysis module specifies the location to the Location. The corresponding URL issues a request; in step 410, the real URL content is returned to the HTTP server A and processed; and in step 412, the HTTP server A returns the real URL content to the HTTP client A40. Further, in step 404, if the URL request initiated by the user is not processed by the redirect, the HTTP server A still forwards the URL request to the redirect analysis module after processing; if the URL request initiated by the user has been served by the service provider After the redirection process is performed, the HTTP server A processes the URL request, and forwards the result of the URL request back to the redirect analysis module, where the result of the URL request return refers to the destination URL content corresponding to the original URL request of the user. . For example, in this embodiment, the original URL request of the user is http://www.alisoft.com/im/gettip.html, and the result of processing the URL request by the HTTP server A is 3 02http: //www.alisoft.com/portal/getnewtip.html. In other words, regardless of whether the user's original URL request needs to be redirected, the HTTP server A forwards the processing result of the URL request to the redirect analysis module, where the redirect is needed, The result of the processing is the result returned by processing the URL request; in the case where no redirection is required, the processing result is the original URL request. It can be known from the above implementation steps of the present invention that when the user needs to access the URL and send the URL request to the HTTP server 30, the HTTP server 30 is specifically provided with a redirection analysis module 312 to perform a 0-direction determination. Regardless of whether a redirect is required, the HTTP client A40 obtains the real URL content of the original URL request. It should be noted that when the redirection analysis module 302 determines that the redirection is performed, the analysis module needs to send a request to the real URL, and performs a series of processing to return the real URL content to the HTTP server A. 1 and 2 are schematic block diagrams and flow diagrams of a prior art HTTP client sending a URL request to an HTTP server; and FIGS. 3 and 4 illustrate an HTTP client transmitting to an HTTP server in the present invention. Schematic diagram and flow diagram of the URL request. In the following, for the difference between the prior art and the present invention, when the HTTP client sends a URL request to the HTTP server, FIG. 5 shows a comparison diagram of the implementation of the application and the prior art in the HTTP request service. 5A shows a schematic diagram of a process in which the HTTP client sends a URL request to return a real URL content in the prior art; FIG. 5B shows a schematic diagram of a process in which the HTTP client sends a URL request to return a real URL content in the present invention.

參照圖5A ’在HTTP用戶端A100、HTTP服務端 A102和HTTP服務端B106的交互關係中,首先,HTTP -15- 201039591 用戶端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服務端 A3 00的交互關係中,HTTP用戶端A40向HTTP服務端 A3 00發送原始URL請求,無論該URL請求是否由服務商 重定向到另一新的URL,HTTP服務端 A3 00均直接向 HTTP用戶端A40返回真實URL內容。與圖5A相比,位 於HTTP用戶端A4 0的用戶體驗感較好,因爲從某種意義 上來說,用戶只關心通過原始URL請求所獲得的真實 URL內容,而無需關注是否先返回重定向命令和重定向 URL,然後根據該重定向命令和重定向URL向HTTP服務 端發送URL請求以得到真實URL內容。 再次結合圖5A和圖5B,雖然圖5B中的HTTP服務 端A利用重定向分析模組302來對重定向進行處理,但 是,從HTTP用戶端A40來看,用戶只需發送URL請求 就能夠獲取與該URL請求相對應的真實URL內容,這樣 就使得HTTP用戶端與HTTP伺服器之間的交互更爲友 -16- 201039591 好,更節省網路帶寬;而且從HTTP 大地減少了 HTTP用戶端向HTTP伺月 數目。 上文中,參照附圖描述了本發明 是,本領域中的普通技術人員能夠理 的精神和範圍的情況下’還可以對本 作各種變更和替換。這些變更和替換 利範圍所限定的範圍內。 【圖式簡單說明】 讀者在參照附圖閱讀了本發明的 將會更清楚地瞭解本發明的各個方面 圖1示出了現有技術中HTTP用 發送URL請求的原理方塊圖; 圖2示出了圖1所示的HTTP用 發送URL請求的流程示意圖; 圖3示出了本發明中HTTP用戶 送URL請求的原理方塊圖; 圖4示出了圖3所示的HTTP用 發送URL請求的流程示意圖;以及 圖5示出了現有技術與本發明申 HTTP伺服器發送URL請求的比較示 出了現有技術中HTTP用戶端從發送 實URL內容的進程不意圖;和圖 伺服器3 0來看,極 艮器發送的URL請求 的具體實施方式。但 解,在不偏離本發明 發明的具體實施方式 都落在本發明申請專 具體實施方式以後, 。其中, 戶端向HTTP伺服器 戶端向HTTP伺服器 端向HTTP伺服器發 戶端向HTTP伺服器 請的HTTP用戶端向 意圖,其中圖5A示 URL請求到返回真 5B示出了本發明中 -17- 201039591 HTTP用戶端從發送URL請求到返回真實URL內容的進 程示意圖。 【主要元件符號說明】Referring to FIG. 5A 'in the interaction relationship between the HTTP client A100, the HTTP server A 102, and the HTTP server B 106, first, the HTTP -15-201039591 client A100 sends a URL request to the HTTP server A 102, and is returned by the HTTP server A 100. The redirected command and the redirect URL are sent to the HTTP client A100; then, the redirected URL request is sent by the HTTP client A100 to the HTTP server B 106, and the HTTP server B 106 returns the real URL content to the HTTP client A100. It is not difficult to see that whether the HTTP server A102 and the HTTP server B106 belong to the same server, the HTTP client A100 needs to send two URL requests to the HTTP server, which invisibly requires additional network bandwidth and users. The experience is relatively poor. Referring to FIG. 5B, in the interaction relationship between the HTTP client A40 and the HTTP server A3 00, the HTTP client A40 sends an original URL request to the HTTP server A3 00, regardless of whether the URL request is redirected by the service provider to another new one. The URL, HTTP server A3 00 returns the real URL content directly to the HTTP client A40. Compared with FIG. 5A, the user experience at the HTTP client A40 is better, because in a sense, the user only cares about the real URL content obtained through the original URL request, without paying attention to whether to return the redirect command first. And redirecting the URL, and then sending a URL request to the HTTP server according to the redirect command and the redirect URL to get the real URL content. 5A and 5B, although the HTTP server A in FIG. 5B uses the redirection analysis module 302 to process the redirection, from the perspective of the HTTP client A40, the user can obtain the URL request only. The real URL content corresponding to the URL request, so that the interaction between the HTTP client and the HTTP server is more friendly - 16-201039591, which saves network bandwidth; and reduces the HTTP client direction from HTTP. The number of HTTP servers. The present invention has been described above with reference to the accompanying drawings, and various modifications and substitutions are possible in the present invention. These changes and replacements are within the limits defined by the scope. BRIEF DESCRIPTION OF THE DRAWINGS The reader will be able to more clearly understand the various aspects of the present invention by reading the present invention with reference to the accompanying drawings. FIG. 1 is a block diagram showing the principle of sending a URL request for HTTP in the prior art; FIG. 2 shows FIG. 1 is a schematic block diagram of an HTTP user sending a URL request in FIG. 1; FIG. 3 is a schematic block diagram showing an HTTP user sending a URL request in the present invention; FIG. 4 is a flow chart showing the HTTP sending URL request shown in FIG. And FIG. 5 shows a comparison between the prior art and the present invention for sending a URL request by the HTTP server. The prior art shows that the HTTP client does not intend to send the real URL content; and the graph server 30 looks at the pole. The specific implementation of the URL request sent by the device. However, the specific embodiments of the invention are not deviated from the specific embodiments of the invention. The client sends an HTTP client to the HTTP server from the HTTP server to the HTTP server to the intent, and the URL request to return true 5B is shown in the present invention. -17- 201039591 Schematic diagram of the process from the HTTP client to the return of the real URL content. [Main component symbol description]

30 : HTTP伺服器 40: HTTP用戶端A 50 :目的URL內容 60 :真實URL內容 100 : HTTP用戶端 102 : HTTP伺服器端A 1 04 :目的URL內容 106 : HTTP伺服器端B 108 :真實URL內容 3 00 : HTTP月艮務端A 3 0 2 :重定向分析模組 -18-30: HTTP server 40: HTTP client A 50: destination URL content 60: real URL content 100: HTTP client 102: HTTP server A 1 04: destination URL content 106: HTTP server side B 108: real URL Content 3 00 : HTTP monthly server A 3 0 2 : Redirection analysis module -18-

Claims (1)

201039591 七、申請專利範圍 1· 一種用於實現HTTP請求服務的系統,其特徵在 於,該系統至少包括: • HTTP用戶端,用於發送用戶的URL請求;以及 HTTP伺服器,用於接收該HTTP用戶端的URL請 求’並直接返回用戶所期望的真實URL內容至該HTTP 用戶端。 〇 2.如申請專利範圍第1項之系統,其中,該HTTP 伺服器還包括HTTP服務端和重定向分析模組,其中,該 HTTP服務端接收來自HTTP用戶端的URL請求並進行處 理;以及該重定向分析模組接收該HTTP服務端的處理結 果並判斷是否需要進行重定向。 3-如申請專利範圍第2項之系統,其中,該重定向 分析模組確定需要重定向時,向重定向的URL發送請 求,並返回具有HTTP協定頭的結果;以及當該HTTP協 Q 定頭中的命令字爲3 0 1 /3 02/3 03/3 07並具有Location協定 頭和相應的URL時,該重定向分析模組向該相應的URL 發送請求。 4. 如申請專利範圍第2項之系統,其中,該重定向 分析模組將真實URL內容返回至該HTTP服務端。 5. 如申請專利範圍第1項之系統,其中,該HTTP 用戶端接收用戶所期望的真實URL內容與該HTTP用戶 端是否支援重定向功能無關。 6. 如申請專利範圍第1項之系統,其中,該HTTP -19- 201039591 用戶端接收用戶所期望的真實URL內容與該重定向分析 模組的判斷結果無關。 7. 如申請專利範圍第1項之系統,其中,該用戶請 求的URL與該重定向分析模組返回的URL對應於不同的 HTTP伺服器。 8. 如申請專利範圍第1項之系統,其中,該用戶請 求的URL與該重定向分析模組返回的URL對應於相同的 HTTP伺服器。 9. 一種用於實現HTTP請求服務的方法,其特徵在 於,該方法包括步驟: HTTP用戶端向HTTP服務端發送URL請求; 該HTTP服務端接收和處理該URL請求,並將處理 結果轉發至重定向分析模組; 該重定向分析模組判斷是否需要進行重定向,當確定 予以重定向時,該重定向分析模組向該相應的URL發送 請求;和 該HTTP服務端接收來自該重定向分析模組的真實 URL內容,並直接發送至該HTTP用戶端。 10. 如申請專利範圍第9項之方法,其中,當需要重 定向時,該重定向分析模組向重定向的URL發送請求, 並返回具有HTTP協定頭的結果;並且當該HTTP協定頭 中的命令字爲30 1 /302/3 03/3 07且具有Location協定頭和 相應的URL時,該重定向分析模組向該相應的URL發送 請求。 -20- 201039591 11. 如申請專利範圍第9項之方法,其中,當弃 定向時,該重定向分析模組將接收的URL請求直g 至該HTTP服務端。 12. 如申請專利範圍第9項之方法,其中,該 服務端和該重定向分析模組放置在HTTP伺服器中。 13. 如申請專利範圍第9項之方法,其中,該 用戶端接收用戶所期望的真實URL內容與該HTTP 0 端是否支援重定向功能無關。 14. 如申請專利範圍第9項之方法,其中,該 用戶端接收用戶所期望的真實URL內容與該重定[έ 模組的判斷結果無關。 15. 如申請專利範圍第9項之方法,其中,該月 求的URL與該重定向分析模組返回的URL對應於1 HTTP伺服器。 16. 如申請專利範圍第9項之方法,其中,該月 〇 求的URL與該重定向分析模組返回的URL對應於牛| HTTP伺服器。 丨需重 ;返回 HTTP HTTP 用戶 HTTP 分析 丨戶請 :同的 戶請 丨同的 -21 -201039591 VII. Patent Application Scope 1. A system for implementing an HTTP request service, the system comprising: at least: an HTTP client for sending a URL request of a user; and an HTTP server for receiving the HTTP The client's URL request 'returns directly to the user's desired real URL content to the HTTP client. 2. The system of claim 1, wherein the HTTP server further comprises an HTTP server and a redirection analysis module, wherein the HTTP server receives the URL request from the HTTP client and processes the same; The redirection analysis module receives the processing result of the HTTP server and determines whether redirection is required. 3. The system of claim 2, wherein the redirect analysis module determines that a redirect is needed, sends a request to the redirected URL, and returns a result having an HTTP protocol header; and when the HTTP protocol is determined When the command word in the header is 3 0 1 /3 02/3 03/3 07 and has the Location contract header and the corresponding URL, the redirect analysis module sends a request to the corresponding URL. 4. The system of claim 2, wherein the redirect analysis module returns the real URL content to the HTTP server. 5. The system of claim 1, wherein the HTTP client receives the real URL content desired by the user regardless of whether the HTTP client supports the redirect function. 6. The system of claim 1, wherein the HTTP -19-201039591 client receives the real URL content expected by the user regardless of the result of the redirection analysis module. 7. The system of claim 1, wherein the URL requested by the user corresponds to a different HTTP server than the URL returned by the redirect analysis module. 8. The system of claim 1, wherein the URL requested by the user corresponds to the same HTTP server as the URL returned by the redirect analysis module. 9. A method for implementing an HTTP request service, the method comprising the steps of: an HTTP client sending a URL request to an HTTP server; the HTTP server receiving and processing the URL request, and forwarding the processing result to a heavy a directional analysis module; the redirection analysis module determines whether redirection is required, and when it is determined to be redirected, the redirection analysis module sends a request to the corresponding URL; and the HTTP server receives the redirection analysis The actual URL content of the module is sent directly to the HTTP client. 10. The method of claim 9, wherein the redirect analysis module sends a request to the redirected URL and returns a result with an HTTP protocol header when the redirect is needed; and when the HTTP protocol header is When the command word is 30 1 /302/3 03/3 07 and has a Location contract header and a corresponding URL, the redirect analysis module sends a request to the corresponding URL. -20- 201039591 11. The method of claim 9, wherein the redirect analysis module directs the received URL request to the HTTP server when the orientation is discarded. 12. The method of claim 9, wherein the server and the redirect analysis module are placed in an HTTP server. 13. The method of claim 9, wherein the client receives the real URL content desired by the user regardless of whether the HTTP 0 side supports the redirection function. 14. The method of claim 9, wherein the client receives the real URL content desired by the user regardless of the re-determination result of the module. 15. The method of claim 9, wherein the URL requested for the month corresponds to an HTTP server returned by the redirect analysis module. 16. The method of claim 9, wherein the URL requested for the month corresponds to the URL returned by the redirect analysis module to the HTTP server. Do not need to be heavy; return HTTP HTTP user HTTP analysis Set up please: the same user please agree -21 -
TW98114032A 2009-04-28 2009-04-28 A system for implementing an HTTP request service and a method thereof TWI472205B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
TW98114032A TWI472205B (en) 2009-04-28 2009-04-28 A system for implementing an HTTP request service and a method thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
TW98114032A TWI472205B (en) 2009-04-28 2009-04-28 A system for implementing an HTTP request service and a method thereof

Publications (2)

Publication Number Publication Date
TW201039591A true TW201039591A (en) 2010-11-01
TWI472205B TWI472205B (en) 2015-02-01

Family

ID=44995578

Family Applications (1)

Application Number Title Priority Date Filing Date
TW98114032A TWI472205B (en) 2009-04-28 2009-04-28 A system for implementing an HTTP request service and a method thereof

Country Status (1)

Country Link
TW (1) TWI472205B (en)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4852938B2 (en) * 2005-09-02 2012-01-11 富士ゼロックス株式会社 Data server, data management method and program

Also Published As

Publication number Publication date
TWI472205B (en) 2015-02-01

Similar Documents

Publication Publication Date Title
US10778554B2 (en) Latency measurement in resource requests
US9912740B2 (en) Latency measurement in resource requests
US9253065B2 (en) Latency measurement in resource requests
US9241042B2 (en) In-server redirection of HTTP requests
US9185012B2 (en) Latency measurement in resource requests
US8984164B2 (en) Methods for reducing latency in network connections and systems thereof
US8526405B2 (en) Routing network requests based on requesting device characteristics
US9444780B1 (en) Content provided DNS resolution validation and use
CN102171673B (en) Cross-layer pipelining optimizations for reduced roundtrips and improving quality of experience
US20100223355A1 (en) Method for page redirection and WAP gateway
US8868638B2 (en) Methods for reducing latency in network connections using automatic redirects and systems thereof
US7406496B2 (en) System and method for processing callback requests, which include a client port and address, included in web-based procedure calls
TW201039591A (en) System and method for realizing HTTP request service
JP5806067B2 (en) Server apparatus and server apparatus control method
JPWO2009035030A1 (en) COMMUNICATION SYSTEM, COMMUNICATION OPTIMIZATION DEVICE, AND COMMUNICATION NETWORK ESTIMATING METHOD USED FOR THEM
GB2503284A (en) Processing browser sessions in accordance with modification rules

Legal Events

Date Code Title Description
MM4A Annulment or lapse of patent due to non-payment of fees