今天在做一個進度條的時候遇到一個問題,我在session裡面存放了一個計數器,當爬取到一條資料的時候這個值+1,然後前台每隔3s中擷取一次session的這個值,但是問題出來了,在FF下面,得到的值都是正常的,但是在IE下面死活都是之前的值,只有當重新開啟頁面的時候才能擷取到最新的 session值:
下面是我的proBar.jsp的代碼:
<%@ page language="java" import="java.util.*" pageEncoding="UTF-"%><%String path = request.getContextPath();String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";%><script type="text/javascript" src="<%=path %>/js/jquery.js"></script><script type="text/javascript" src="<%=path%>/js/jquery.progressbar.min.js"></script><script type="text/javascript">function createXMLHttpRequest() { var xmlHttp; if (window.ActiveXObject) { xmlHttp = new ActiveXObject("Microsoft.XMLHTTP"); } else { xmlHttp = new XMLHttpRequest(); } return xmlHttp; } function btn_click() { var xmlHttp; xmlHttp = createXMLHttpRequest(); xmlHttp.onreadystatechange = processor; //xmlHttp.open("GET", "/jbbs/servlet/ControlCrawl?method=getinforsize", true); xmlHttp.open("POST", "/jbbs/servlet/ControlCrawl?method=getinforsize", true); xmlHttp.send(null); function processor() { ....... } } var action=setInterval("btn_click();", ); </script><span>爬取進度:</span><br/><div id="container"></div>
後來把GET改為POST就正常了。
PS:關於HTTP的GET和POST
Http定義了與伺服器互動的不同方法,最基本的方法有4種,分別是GET,POST,PUT,DELETE。URL全稱是資源描述符,我們可以這樣認 為:一個URL地址,它用於描述一個網路上的資源,而HTTP中的GET,POST,PUT,DELETE就對應著對這個資源的查,改,增,刪4個操作。 到這裡,大家應該有個大概的瞭解了,GET一般用於擷取/查詢資源資訊,而POST一般用於更新資源資訊。
1.根據HTTP規範,GET用於資訊擷取,而且應該是安全的和等冪的。
(1).所謂安全的意味著該操作用於擷取資訊而非修改資訊。換句話說,GET 請求一般不應產生副作用。就是說,它僅僅是擷取資源資訊,就像資料庫查詢一樣,不會修改,增加資料,不會影響資源的狀態。
* 注意:這裡安全的含義僅僅是指是非修改資訊。
(2).等冪的意味著對同一URL的多個請求應該返回同樣的結果。
等冪(idempotent、idempotence)是一個數學或電腦學概念,常見於抽象代數中。
等冪有一下幾種定義:
對於單目運算,如果一個運算對於在範圍內的所有的一個數多次進行該運算所得的結果和進行一次該運算所得的結果是一樣的,那麼我們就稱該運算是等冪的。比如絕對值運算就是一個例子,在實數集中,有abs(a)=abs(abs(a))。
對於雙目運算,則要求當參與運算的兩個值是等值的情況下,如果滿足運算結果與參與運算的兩個值相等,則稱該運算等冪,如求兩個數的最大值的函數,有在在實數集中等冪,即max(x,x) = x。
但在實際應用中,以上2條規定並沒有這麼嚴格。引用別人文章的例子:比如,新聞網站的頭版不斷更新。雖然第二次請求會返回不同的一批新聞,該操作仍然被認為是安全的和等冪的,因為它總是返回當前的新聞。從根本上說,如果目標是當使用者開啟一個連結時,他可以確信從自身的角度來看沒有改變資源即可。
2.根據HTTP規範,POST表示可能修改變伺服器上的資源的請求。
繼續引用上面的例子:還是新聞以網站為例,讀者對新聞發表自己的評論應該通過POST實現,因為在評論提交後網站的資源已經不同了,或者說資源被修改了。
但在實際的做的時候,很多人卻沒有按照HTTP規範去做,導致這個問題的原因有很多,比如說:
1.很多人貪方便,更新資源時用了GET,因為用POST必須要到FORM(表單),這樣會麻煩一點。
2.對資源的增,刪,改,查操作,其實都可以通過GET/POST完成,不需要用到PUT和DELETE。
3.另外一個是,早期的Web MVC架構設計者們並沒有有意識地將URL當作抽象的資源來看待和設計,所以導致一個比較嚴重的問題是傳統的Web MVC架構基本上都只支援GET和POST兩種HTTP方法,而不支援PUT和DELETE方法。
* 關於MVC:
MVC本來是存在於Desktop程式中的,M是指資料模型,V是指使用者介面,C則是控制器。使用MVC的目的是將M和V的實現代碼分離,從而使同一個程式可以使用不同的表現形式。
以 上3點典型地描述了老一套的風格(沒有嚴格遵守HTTP規範),隨著架構的發展,現在出現REST(RepresentationalState Transfer),一套支援HTTP規範的新風格,這裡不多說了,可以參考《RESTful Web Services》。
再從表面現像上面看看GET和POST的區別:
(1). 首先是"GET方式提交的資料最多隻能是1024位元組",因為GET是通過URL提交資料,那麼GET可提交的資料量就跟URL的長度有直接關係了。而實 際上,URL不存在參數上限的問題,HTTP協議規範沒有對URL長度進行限制。這個限制是特定的瀏覽器及伺服器對它的限制。IE對URL長度的限制是 2083位元組(2K+35)。對於其他瀏覽器,如Netscape、FireFox等,理論上沒有長度限制,其限制取決於作業系統的支援。注意這是限制是 整個URL長度,而不僅僅是你的參數值資料長度。
(2).理論上講,POST是沒有大小限制的,HTTP協議規範也沒有進行大小限制,說“POST資料量存在80K/100K的大小限制”是不準確的,POST資料是沒有限制的,起限制作用的是伺服器的處理常式的處理能力。
對於ASP程式,Request對象處理每個表單域時存在100K的資料長度限制。但如果使用Request.BinaryRead則沒有這個限制。
由這個延伸出去,對於IIS 6.0,微軟出於安全考慮,加大了限制。
我們還需要注意:
1).IIS 6.0預設ASP POST資料量最大為200KB,每個表單域限制是100KB。
2).IIS 6.0預設上傳檔案的最大大小是4MB。
3).IIS 6.0預設最大要求標頭是16KB。
IIS 6.0之前沒有這些限制。
所以上面的80K,100K可能只是預設值而已(註:關於IIS4和IIS5的參數,我還沒有確認),但肯定是可以自己設定的。由於每個版本的IIS 對這些參數的預設值都不一樣,具體請參考相關的IIS配置文檔。
3.在ASP中,服務端擷取GET請求參數用Request.QueryString,擷取POST請求參數用Request.Form。
在JSP 中,用request.getParameter(\"XXXX\")來擷取,雖然jsp中也有request.getQueryString()方法, 但使用起來比較麻煩,比如:傳一個test.jsp?name=hyddd&password=hyddd,用request.getQueryString()得到的是:name=hyddd&password=hyddd。在PHP中,可以 用$_GET和$_POST分別擷取GET和POST中的資料,而$_REQUEST則可以擷取GET和POST兩種請求中的資料。值得注意的是,JSP 中使用request和PHP中使用$_REQUEST都會有隱患,這個下次再寫個文章總結。
4.POST的安全性要比GET的安全性高。
注意:這裡所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作資料修 改,而這裡安全的含義是真正的Security的含義,比如:通過GET提交資料,使用者名稱和密碼將明文出現在URL上,因為(1)登入頁面有可能被瀏覽器 緩衝,(2)其他人查看瀏覽器的曆史紀錄,那麼別人就可以拿到你的帳號和密碼了,除此之外,使用GET提交資料還可能會造成Cross-site request forgery攻擊。
總結一下,Get是向伺服器發索取資料的一種請求,而Post是向伺服器提交資料的一種請求,在FORM(表單)中,Method預設為"GET",實質上,GET和POST只是發送機制不同,並不是一個取一個發!
以上是小編跟大家分享的Ajax訪問不斷變化的session的值不一致解決方案以及HTTP協議中的GET、POST的區別,希望對大家有用,欲瞭解更多有關ajax session 不一致問題,請持續關注本站。