這是springmvc中的***的配置
當我沒有在***中配置相應的url，直接在位址列中鍵入請求位址是會被攔截然後重定向到登入頁面。
但是在工作中發現了另乙個問題就是，如果我不配置url。
但是在某個controller中的乙個方法請求**到另乙個方法，而這個方法從頁面獲取引數時用的是jquery的ajax，其中就包含會被攔截的url（既是沒有在配置檔案中配置相應的url）。
如下圖js中的一段**所示：
那麼當我去請求的時候就會有這樣的情況出現
1， 該js是可行的，因為判斷不為空時（js中有判斷**）可以執行，如下圖：
2，但是利用ajax請求時，路徑出了問題導致一下情況：
也就是請求出錯了，根據以上的url請求失敗。
再來看一下瀏覽器中除錯，看看header裡面的內容：
3，當我從位址列中鍵入請求位址時，會被攔截，但我登入的登入頁面之後，再鍵入請求位址，此時是成功的。
得到相應的json資料。
4， 這個時候再來看看之前利用請求**的位址再到該頁面
5，這個時候再來看看response header裡的資訊
（是否真是這裡的原因不敢確定）
這個時候，就像配置檔案中配置該請求位址一樣了。
是最重要的規則。這個字段用於指定所有快取機制在整個請求
/響應鏈中必須服從的指令。這些指令指定用於阻止快取對請求或響應造成不利干擾的行為。這些指令通常覆蓋預設快取演算法。快取指令是單向的，即請求中存在乙個指令並不意味著響應中將存在同乙個指令。
總結：發現乙個有趣的情況
此種情況***沒有攔截相應的請求url。待以後再深入研究（必定是關於許可權和快取）。
謝謝指出問題，指教......
通過HelloSpring了解Spring的IOC
在dao層建立乙個hello實體類。package dao public class hello public void setstr string str override public string tostring 然後要輸出就要建立物件，在spring中，有乙個ioc池，需要使用物件就在池裡...
1019 數字黑洞（sscanf和sprintf）
給定任乙個各位數字不完全相同的 4 位正整數，如果我們先把 4 個數字按非遞增排序，再按非遞減排序，然後用第 1 個數字減第 2 個數字，將得到乙個新的數字。一直重複這樣做，我們很快會停在有 數字黑洞 之稱的 6174，這個神奇的數字也叫 kaprekar 常數。例如，我們從6767開始，將得到 7...
SpringMVC學習筆記之與Spring的關係
需要進行 spring 整合 springmvc 嗎 還是否需要再加入 spring 的 ioc 容器嗎 是否需要再 web.xml 檔案中配置啟動 spring ioc 容器 contextloaderlistener 嗎 需要 通常情況下，類似於資料來源 事務 整合其它框架都是放在spring ...