Ajax cache problem requestheader

This is to reduce the unnecessary burden caused by frequent access to the server, but it also brings some problems that the special business logic cannot meet.
For example:
You need to use a select drop-down list at the front end as the ajax trigger entry, present the information returned by the server on the page, and update the actual logic operations to the session or database.
When the option is switched for the first time, that is, when the request is submitted, everything is normal. However, if the same option is switched because of the browser cache, it will not go to the server, the actual dynamic information is obtained from the cache. The background logic is not moved. The Code is as follows:
Aspx code Copy codeThe Code is as follows: <asp: DropDownList ID = "ddlProductList" runat = "server">
<Asp: ListItem Value = "" Selected = "True"> </asp: ListItem>
<Asp: ListItem Value = "null"> dynamic fixed-rate dynamic renewal </asp: ListItem>
<Asp: ListItem Value = "QIWL"> define QIWL (H9) </asp: ListItem>
<Asp: ListItem Value = "KIWL"> export KIWL (H11) </asp: ListItem>
<Asp: ListItem Value = "JIWL"> paijiwl (H15) </asp: ListItem>
<Asp: ListItem Value = "null"> dynamic price (market gold and profit) </asp: ListItem>
<Asp: ListItem Value = "IIWL"> merge IIWL </asp: ListItem>
<Asp: ListItem Value = "HIWL"> history HIWL </asp: ListItem>
<Asp: ListItem Value = "null"> dynamic fixed-rate dynamic sequence of Life Insurance </asp: ListItem>
<Asp: ListItem Value = "KIWLS"> javaskiwls </asp: ListItem>
<Asp: ListItem Value = "null"> creation of dynamic Value-based automatic renewal </asp: ListItem>
<Asp: ListItem Value = "ODIWL"> using ODIWL </asp: ListItem>
<Asp: ListItem Value = "JDIWL"> using JDIWL </asp: ListItem>
<Asp: ListItem Value = "HDIWL"> using HDIWL </asp: ListItem>
<Asp: ListItem Value = "null"> fixed-rate dynamic old-cost insurance (MI) </asp: ListItem>
<Asp: ListItem Value = "JDISE"> using JDISE </asp: ListItem>
</Asp: DropDownList>

Aspx. cs codeCopy codeThe Code is as follows: if (! IsPostBack)
{
// Add client events for doropdownlist
DdlProductList. Attributes. Add ("onchange", "selectChange (this )");
}

Ajax. js CodeCopy codeThe Code is as follows: var request;
Function selectChange (obj ){
CreateHttpRequest ();
Var url = "AjaxService. aspx? Product = "+ obj. value;
Request. open ("GET", url, true)
Request. onreadystatechange = resetRate;
Request. send ();
Return false;
}
Function createHttpRequest (){
If (window. ActiveXObject ){
Request = new ActiveXObject ("Microsoft. XMLHTTP ");
} Else if (window. XMLHttpRequest ){
Request = new XMLHttpRequest ();
}
}
Function resetRate (){
If (request. readyState = 4 ){
If (request. responseText. substring (0, 1) = "#"){
Document. getElementById ("systemErrorMsg"). innerHTML = request. responseText. substring (1 );
Document. getElementById ("rate"). innerHTML = "";
} Else {
Document. getElementById ("rate"). innerHTML = request. responseText;
Document. getElementById ("systemErrorMsg"). innerHTML = "";
}
}
}

Request Page codeCopy codeThe Code is as follows: protected void Page_Load (object sender, EventArgs e)
{
String productShortName = Request. QueryString ["product"];
If (productShortName! = Null & productShortName! = "Null ")
{
String result = Utility. GetProductRate (packageName );
Session ["rate"] = result;
Response. Write (result );
}
}

After analysis, the problem lies in the XmlHttpRequest object. After switching the options, the logic does not go to the request page every time. The solution is as follows:
Request. setRequestHeader ("If-Modified-Since", "0 ");
In short, Last-Modified and If-Modified-Since are both HTTP header information used to record the Last modification time of the page, but Last-Modified is the HTTP header sent by the server to the client, if-Modified-Since is the header sent by the client to the server. You can see that when you request a local cache page again, the client sends the Last Modified timestamp of Last-Modified sent from the previous server back through the If-Modified-Since header to the server for verification, this timestamp is used to determine whether the client page is the latest. If it is not the latest, new content is returned. If it is the latest, then, 304 is returned to inform the client that the page of the local cache is the latest, so the client can directly load the page from the local, so that the data transmitted over the network will be greatly reduced, it also reduces the burden on the server.
In addition, there is another solution for release, but it is not tested yet. Theoretically, it should be feasible to set the response header on the request page:
Response. AddHeader ("Cache-control", "no-cache ");