1.在index頁面中設定了
得到如下鏈結
當這個get請求發出的時候，流程是這樣的：
首先，它被webx中配置的filter捕獲：
進入原始碼分析發現：該請求進入了webxframeworkfilter的dofilter方法:
使用getresourcepath（request）得到path，然後通過i***cluded方法進行判斷是否不進行處理。
不進行處理的urlpattern在配置中進行了配置。
顯然最後返回false，不排除在外，因此webx接管了這個請求url。
之後getwebxcomponents.getwebxrootcontroller.service;
getwebxcomponents得到配置中配置的所有components。然後獲得處理web請求的webxrootcontroller，執行它的service方法，入參為原始的httpservletrequest和httpservletresponse，以及配置中配置的filterchain.
然後進入service方法進行請求的分類：
// 請求未結束，則繼續處理...
request = requestcontext.getrequest();
response = requestcontext.getresponse();
// 如果是乙個內部請求，則執行內部請求
if (handleinternalrequest(request, response))
// 如果不是內部的請求，並且沒有被passthru，則執行handlerequest
if (isrequestpassedthru(request) || !handlerequest(requestcontext))
} catch (throwable e) finally
}其中有handleinternalrequest和 處理非內部請求的**塊。
接下來判斷是否是內部請求,該方法在是內部請求之後會執行然後返回true：
// 如果是乙個內部請求，則執行內部請求
internalrequesthandlercontext.handlerequest();
return
true;
}顯然本例中返回了false，意味著它不是內部請求，它是乙個外部的通過頁面傳來的鏈結。
在判斷了既不是paththru的請求也不是內部請求，進入if中的handlerequest（requestcontext）
尋找path對應的components。
public webxcomponent findmatchedcomponent(string path)
webxcomponent defaultcomponent = getdefaultcomponent();
webxcomponent matched = null;
// 字首匹配componentpath。
for (webxcomponent component : this)
string componentpath = component.getcomponentpath();
if (!path.startswith(componentpath))
// path剛好等於componentpath，或者path以componentpath/為字首
if (path.length() == componentpath.length() || path.charat(componentpath.length()) == '/')
}// fallback to default component
if (matched == null)
return matched;
}
然後將該component放入request作為引數，再進入service的handle.invoke（）：
執行invokenext（）
public
void invokenext()
try
executedindex++;
if (executingindex < valves.length) : {}", desccurrentvalve(), valve);
}valve.invoke(this);
} catch (pipelineexception e) catch (exception e) finally : {}", desccurrentvalve(), valve);}}
if (executedindex < valves.length && executedindex == executingindex) execution was interrupted by {}: {}", new object );}}
} else reaches its end.", desccurrentpipeline());}}
} finally
}
這是乙個遞迴執行過程，將this物件傳入下乙個valve進行處理，然後再層層深入，直到完成配置中配置的valve流程再一層層返回。
而我們所定義的業務層的方法，也就在每乙個valve中，不同種類的valve**著不同的業務方法，這也就是為什麼有的業務方法使用execute命名，有的使用do***作為方法名：
最終boolean返回served=true；完成請求並commitrequest。
乙個url請求的流程
網域名稱解析就是根據url來獲取對應的ip的過程。瀏覽器 會首先會去搜尋瀏覽器自身的dns快取 如果找到了url對應的ip就直接返回 如果瀏覽器自身的快取裡面沒有找到對應的條目，那麼瀏覽器會搜尋作業系統自身的dns快取,如果找到且沒有過期則停止搜尋解析到此結束.如果在os的dns快取裡也沒找到，那麼...
Django學習 3 請求流程
django請求生命週期 url對應關係 匹配 檢視函式 返回使用者字串 url對應關係 匹配 檢視函式 開啟乙個html檔案，讀取內容 1.瀏覽器客戶端請求首先到達專案名資料夾下的urls.py urlpatterns url r include url r include urlpatterns...
Spring MVC請求處理流程及原始碼分析
從接受請求到返回響應，spring mvc框架的眾多元件都伸胳膊挽袖子行動起來，各司其職，有條不紊地完成份內的工作。在整個框架中，dispatcherservlet處於核心的位置，它負責協調和組織不同元件，共同完成請求響應的工作。和大多數web mvc框架一樣，spring mvc通過乙個前端ser...