您好,登錄后才能下訂單哦!
這篇文章主要講解了“Servlet中/和/*的區(qū)別是什么”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“Servlet中/和/*的區(qū)別是什么”吧!
本文提綱
版本約定
?正文
點撥“市面上”的錯誤答案
1、/用于Servlet,/*用于Filter
2、/不會匹配.jsp請求,而/*可以匹配到.jsp請求
3、/*匹配范圍比/大
4、/匹配所有url(路徑+后綴),/*只匹配路徑型
Servlet四種匹配方式
1. 精確匹配
2. 路徑匹配
3. 后綴名匹配
4. 缺省匹配
URL匹配注意事項
匹配順序
/和/*的區(qū)別
DispatcherServlet不攔截.jsp請求根因分析
?總結(jié)
JDK:8
Servlet:4.x
tomcat:9.x
什么樣的答案終身難忘?學(xué)生時代關(guān)于記憶經(jīng)常能聽見兩種論調(diào):
死記硬背:見效快,但也忘得快,且一般不會靈活運用(指標不治本)
理解性記憶:見效慢,但記憶持久且會靈活運用(治標又治本)
如果是你,你愿意pick哪種?
正所謂授人以魚不如授人以漁,后者方能形成永久記憶。不謀而合,本文將采用后種講述方式,幫你記憶持久化。
關(guān)于/和/*的區(qū)別這個問題,依稀記得2015年我自學(xué)那會就能把它倆搞得明明白白,并且通過理解形成了“永久記憶”,所以至那會其就從來沒有犯過迷糊,難道我就這么重視基礎(chǔ)么(md,又在吹牛。。。)
如果用谷歌百度一下關(guān)鍵字:/和/*的區(qū)別
,搜索出來的答案不客氣的說,基本全錯?。。?/strong> 錯誤的姿勢基本還一模一樣,原因你懂的。
各種錯誤case,且聽我娓娓道來。搜集了下有如下4種主流答案,一一點撥。
環(huán)境說明:使用原生Servlet,war包方式部署至外置Tomcat作為服務(wù)器,端口號8080,context-path為:appcontext
反例:
@WebFilter(urlPatterns = {"/*"}) public class FakeServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { System.out.println("FakeServlet收到請求:" + req.getRequestURI()); } }
啟動服務(wù)器,瀏覽器訪問:http://localhost:8080/appcontext/api/demo1,控制臺輸出:
FakeServlet收到請求:/appcontext/api/demo1
一般來講/
確實用于Servlet,/*
用于Filter,但并不代表這是正確的。
說明:Filter路徑模式使用
/
無效
這個結(jié)論表面上看沒有問題,但是往深了想一步,是否能夠推導(dǎo)出這個結(jié)論:“/不會匹配.html請求,而/*可以匹配到.html請求”。試試看:
@WebServlet(urlPatterns = {"/"}) public class FakeServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { System.out.println("FakeServlet收到請求:" + req.getRequestURI()); } } @WebFilter(urlPatterns = {"/*"}) public class FakeFilter extends HttpFilter { @Override protected void doFilter(HttpServletRequest req, HttpServletResponse res, FilterChain chain) throws IOException, ServletException { System.out.println("FakeFilter收到請求:" + req.getRequestURI()); super.doFilter(req, res, chain); } }
啟動服務(wù)器,瀏覽器訪問:http://localhost:8080/appcontext/api/demo1.jsp,控制臺輸出:
FakeFilter收到請求:/appcontext/api/demo1.jsp
servlet并未匹配上,似乎符合此結(jié)論:/不會匹配.jsp請求,而/*可以。
瀏覽器再訪問:http://localhost:8080/appcontext/api/demo1.html
,控制臺輸出:
FakeFilter收到請求:/appcontext/api/demo1.html
FakeServlet收到請求:/appcontext/api/demo1.html
Filter和Servlet都匹配成功,破功了吧!
所以說,局限于該回答本身沒有問題,而問題在于.jsp
后綴是一種特殊的請求,拿特殊案例當做通用結(jié)論肯定是站不住腳的。
通過本文下面的講解你就會知道:/屬于最大的的匹配范圍,而/*
恰好是范圍和/一樣了而已,但/*
的優(yōu)先級比/高,并不是它的匹配范圍比/大。
用一句話反駁:/*
也能匹配上/api/demo1.html這種后綴型url(其實上面已經(jīng)給出示例了)
這4個結(jié)論搜索排名非??壳?,不知誤導(dǎo)了多少小朋友呀。與其每次將信將疑,倒不如花點時間寫代碼自己做個試驗來得靠譜。我一向推崇的代碼多動手,人云亦云不如自己來上一發(fā)。
帶著這幾個?結(jié)論,接下來開始發(fā)大招啦:從根本上帶你理解Servlet規(guī)范的URL匹配機制,從而理解到/
和/*
的區(qū)別,授之以漁讓你終身難忘。
Servlet的urlPatterns路徑映射
說明:本文所指的Servlet是廣義的(規(guī)范),所以也包含F(xiàn)ilter的urlPatterns
Servlet/Filter是服務(wù)端的一段小程序,用于處理Http請求。每個Servlet可以映射1個or多個路徑,在xml時代這么寫(url-pattern標簽可寫多個):
<servlet-mapping> <servlet-name>Demo1Servlet</servlet-name> <url-pattern>/api/demo1</url-pattern> <url-pattern>/api/demo2</url-pattern> </servlet-mapping>
@WebServlet注解方式這么寫:
@WebServlet(urlPatterns = {"/api/demo1", "/api/demo2"}) public class Demo1Servlet extends HttpServlet { ... }
此時,該Servlet就能處理這兩種 URL了。
問題來了,如果希望本Servlet處理某一類請求,該怎么破呢?
一類請求顯然是無法一一枚舉出來的,這時就需要用到Servlet的模式匹配了。urlPatterns除了寫字面量的字符串,還支持pattern模式的字符串(從該屬性的命名你應(yīng)該也能看出來)。
接下來聚焦于Servlet的匹配方式展開詳細講解,這是本文的核心內(nèi)容。
在Servlet規(guī)范中一共約定了四種匹配方式,無一例外,每種方式都非常重要和常用,下面逐一介紹。
顧名思義,urlPatterns是個無通配符的精確字符串,如:
@WebServlet(urlPatterns = {"/api/demo1", "/api/demo2"}) // 精確匹配 public class UrlPatternDemoServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { System.out.printf("收到請求:%s ServletPath:%s PathInfo:%s\n", req.getRequestURI(), req.getServletPath(), req.getPathInfo()); } }
打印里輸出servletPath和pathInfo信息,讓日志更具對比性
瀏覽器訪問http://localhost:8080/appcontext/api/demo1
和/api/demo2
均能收到該請求,控制臺分別打?。?/p>
收到請求:/appcontext/api/demo1 ServletPath:/api/demo1 PathInfo:null
收到請求:/appcontext/api/demo2 ServletPath:/api/demo2 PathInfo:null
pattern規(guī)則:以/
開頭,且以/*
結(jié)尾。如:
@WebServlet(urlPatterns = {"/api/*", "/*"}) // 路徑匹配 public class UrlPatternDemoServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 同上 } }
瀏覽器訪問http://localhost:8080/appcontext/api/demo1
,控制臺輸出(匹配的/api/*
):
收到請求:/appcontext/api/demo1 ServletPath:/api PathInfo:/demo1
訪問http://localhost:8080/appcontext/apiapi/demo1
,控制臺輸出(匹配的/*
:
收到請求:/appcontext/apiapi/demo1 ServletPath: PathInfo:/apiapi/demo1
關(guān)注點:當匹配上/*
模式時,ServletPath的值為空串,但PathInfo的值更為“豐富”了。
patten規(guī)則:以*.
開頭(注意是開頭,所以/api/*.jsp
這么寫是非法的)。如:
@WebServlet(urlPatterns = {"*.jsp", "*.*"}) // 后綴名匹配 public class UrlPatternDemoServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 同上 } }
訪問http://localhost:8080/appcontext/api/demo1
,結(jié)果404,因為沒有后綴嘛;
訪問http://localhost:8080/appcontext/api/demo1.jsp
,控制臺輸出(匹配*.jsp
):
收到請求:/appcontext/api/demo1.jsp ServletPath:/api/demo1.jsp PathInfo:null
訪問http://localhost:8080/appcontext/api/demo1.servlet
,結(jié)果404,因為urlPatterns里沒有匹配.servlet后綴的模式;
訪問http://localhost:8080/appcontext/api/demo1.
,結(jié)果404,原因同上
訪問http://localhost:8080/appcontext/api/demo1.*
,控制臺打?。ㄆヅ?code>*.*):
收到請求:/appcontext/api/demo1.* ServletPath:/api/demo1.* PathInfo:null
發(fā)現(xiàn)沒,這種匹配方式還蠻“特殊”的,需要注意這兩點:
該模式以*.
開頭,后面的均是常量,即使是*
也是常量。比如*.*
匹配的后綴必須是.*
而不能是其它
該匹配方式下,pathInfo永遠是null,servletPath永遠是“全部”
pattern規(guī)則:固定值/
。如:
想一想,這不就是我們熟悉的DispatcherServlet的匹配路徑么?
@WebServlet(urlPatterns = "/") // 缺省匹配 public class UrlPatternDemoServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 同上 } }
這個時候匹配任意路徑。
訪問http://localhost:8080/appcontext,控制臺打?。?/p>
收到請求:/appcontext/ ServletPath:/ PathInfo:null
訪問http://localhost:8080/appcontext/api/demo1
,控制臺打印:
收到請求:/appcontext/api/demo1 ServletPath:/api/demo1 PathInfo:null
訪問http://localhost:8080/appcontext/api/demo1.html
,控制臺打印:
收到請求:/appcontext/api/demo1.html ServletPath:/api/demo1.html PathInfo:null
此匹配規(guī)則下,pathInfo永遠是null,servletPath永遠是“全部”。
關(guān)于pathInfo:pathInfo只有當Servlet是路徑匹配時,才有值。其它情況永遠為null
Servlet對URL的匹配既不是Ant風格,也不是Regex。特殊符號只有單個的*
,且使用位置有強約束,切忌想當然的隨意拼湊。
舉例兩種典型的錯誤理解,應(yīng)該能幫助到你:
/api/*.jsp
:該urlPatterns是非法的,啟動時會報錯“IllegalArgumentException: servlet映射中的[/api/*.jsp]無效”。原因為:
若當路徑匹配,/*
后面不能再有任何東西
若當后綴名匹配,*.
必須是最前面
/api/*/demo
:這個urlPatterns是合法的。只不過它屬于精確匹配,也就是說別看它中間有*
,仍舊有且僅能匹配/api/*/demo
這個請求路徑
有時候一個URL會被多個urlPatterns所匹配,這時誰優(yōu)先呢?
Servlet同樣遵循“國際慣例”:越精確越優(yōu)先,越模糊越靠后。站在pattern模式的角度換句話講就是:范圍越小越優(yōu)先,范圍越大越靠后。
因此Servlet四種匹配方式順序按范圍從小到大(優(yōu)先級從高到底)排序為:精確匹配 > 路徑匹配 > 后綴名匹配 > 缺省匹配。
終于,來到了今天的主菜。
從上至下的閱讀到這里,再看這個問題,是不是覺得答案已經(jīng)浮出水面?那么,最后我還是來總結(jié)一下它倆的異同點:
相同點
絕大部分場景下具有相同的表現(xiàn):匹配所有。
不同點
就是由于它們的相同點(如此相似),所以才讓我們難以區(qū)分。
關(guān)于/
:
servlet中特殊的匹配模式(用在Filter中無效),
因為是缺省匹配代表匹配所有路徑,所以只可能存在一個實例(若存在多個就覆蓋)
優(yōu)先級最低(兜底),這是和/*的最大區(qū)別。它不會覆蓋任何其它的url-pattern,只會覆蓋Servlet容器(如Tomcat)內(nèi)建的DefaultServlet
關(guān)于/*
:
屬于4中匹配模式中的路徑匹配,可用于Servlet和Filter
優(yōu)先級很高(僅次于精確匹配)。所以它會覆蓋所有的后綴名匹配,從而很容易引起404問題,所以這種模式的“傷害性”是非常強的,一般有且僅用在Filter上
/
只能用于Servlet上,/*
一般只用于Filter上。
大家熟悉的Spring MVC的DispatcherServlet的匹配路徑默認就是/
,它會攔截各種各樣的請求,諸如下面這種請求都會攔截:
/api/demo1
/html/demo1.html
/static/main.js
但是,它不會攔截/api/demo1.jsp
這種以.jsp結(jié)尾的請求。據(jù)此現(xiàn)象就出現(xiàn)了:/
不攔.jsp請求而/*
攔截(/*
的范圍比/
大)這種“錯誤”言論。
下面告訴你此現(xiàn)象的根因:Servlet容器(如Tomcat)內(nèi)置有專門匹配.jsp
這種請求的Servlet處理器,如下圖所示:
而后綴名匹配優(yōu)先級高于缺省匹配,所以.jsp
結(jié)尾的請求不會被DispatcherServlet所“截胡”而是交給了JspServlet處理。
有了這波分析后,就問你,是不是就不用死記答案了?是不是就終身難忘啦?
Servlet的urlPatterns匹配方式是學(xué)習(xí)Java Web的重要一環(huán),也是深入理解Spring MVC原理的大門,畢竟Spring MVC依舊是做業(yè)務(wù)開發(fā)的首選,而且還會持續(xù)很久、很久。
本文對Servlet的匹配方式做了全覆蓋講解,包括:
四種匹配方式匹配順序(優(yōu)先級)Servlet和Filter匹配的區(qū)別模式匹配中/
和/*
區(qū)別的根本原因
通過本文希望能讓你不再被Servlet的模式匹配所困擾,更不要被一些似可非可的結(jié)論所迷惑,搖擺不定時大不了編碼驗證一下嘛。
感謝各位的閱讀,以上就是“Servlet中/和/*的區(qū)別是什么”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對Servlet中/和/*的區(qū)別是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關(guān)知識點的文章,歡迎關(guān)注!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。