Servlet API тўлиқ сўров йўлини requestURI сифатида очиб беради ва уни contextPath, servletPath ва pathInfoга ажратади, уларнинг қийматлари сервлет қандай кўринганлигига боғлиқ. Ушбу кириш маълумотларга асосланиб, Spring MVC хандлерни кўрсатишда ишлатиладиган қидирув йўлини аниқлаши керак, бу ўз ўзидан DispatcherServletнинг кўрсатилган йўли бўлиб, contextPath ва ҳар қандай servletMapping префиксини (агар мавжуд бўлса) истисно қилади.
ServletPath ва pathInfo декодланади, бу уларни тўлиқ requestURI билан тўғридан-тўғри таққослашни имконсиз қилади, шунинг учун requestURI декодланиши керак бўлади. Лекин бу ўзига хос муаммоларни келтириб чиқаради, чунки йўлда кодланган резервланган белгилар бўлиши мумкин, мисол учун "/" ёки ";", улар декодлаганидан кейин структурани ўзгартиши мумкин, бу хавфсизлик муаммоларига сабаб бўлиши мумкин. Қолаверса, сервлет контейнерлари servletPathни турли даражада нормаллаштириши мумкин, бу эса startsWithни requestURI билан таққослашни янада имкониятисиз қилади.
Шунинг учун servletPathга боғлиқ бўлишдан қочган маъқул, бу префикс асосли servletPath кўрсатиш тури билан бирга келади. Агар DispatcherServlet одатдаги сервлет сифатида "/" билан кўрсатилган ёки бошқа ҳолда "/*" префикссиз кўрсатилган бўлса ва сервлет контейнерлари 4.0+ версияга эга бўлса, Spring MVC сервлет кўрсатиш турини аниқлай олади ва servletPath ва pathInfoдан тўлиқ қочиши мумкин. Сервлет контейнерлари 3.1да, агар шу кўрсатиш турлари мавжуд бўлса, шунга ўхшаш натижага UrlPathHelperни alwaysUseFullPath=true билан Path Matching орқали таништириш билан эришиш мумкин.
Хушхабар шундаки, стандарт сервлет кўрсатиши "/" нотўғри эмас. Лекин бизда ҳали ҳам бир муаммо бор: requestURIни декодлаш керак, токи биз уни контроллер кўрсатишлари билан таққослашимиз мумкин бўлсин. Бу янадай яхши эмас, чунки резервланган белгиларни декодлаш йўлнинг структурасини ўзгартириши мумкинлигининг эҳтимоли бор. Агар шундай белгилари бўлмаслиги кутилса, уларни блоклаш мумкин (Spring Securityнинг HTTP firewallдаги каби), ёки UrlPathHelperни urlDecode=false билан конфигурация қилиш мумкин, лекин контроллер кўрсатишлари кодланган йўлга мувофиқ келиши керак бўлади, бу эса баъзан қабул қилишга арзимайдган. Бундан ташқари, баъзан DispatcherServlet URL'ни бошқа сервлет билан бўлишга тўғри келади ва бу префикс билан кўрсатишни талаб қилиши мумкин.
Юқоридаги муаммоларни тўлақонли ечиш мумкин, агар PathMatcherдан парсланган PathPatternга ўтсангиз, бу 5.3 версия ҳамда ундан юқорида мавжуд. AntPathMatcherдан фарқи шундаки, унга декодланган қидирув йўли ёки кодланган контроллер кўрсатиши талаб қилинади, парсланган PathPattern йўлнинг парсланган кўриниши, яъни RequestPath, билан йўл сегментларини бирма-бир мувофиқлаштиради. Бу йўл сегментларининг қийматларини ўзгартиришсиз декодлаш ва тозалаш имконини беради. Парсланган PathPattern ҳам servletPath префикс кўрсатишини қўллаб-қувватлайди, агар префикс оддий бўлиб, кодлашга зарурият бўлмаган белгиларни ўз ичига олмаса.
GO TO FULL VERSION