28

これは本当に頭を悩ませています。つまり、FirefoxではなくIEでのみ発生するため、jQueryは事実上ブラウザに依存しないという印象を受けました。私は過去数時間このことをクラックしていて、少なくとも何が起こっているのかを突き止めてきました。

このjqGrid:

$("#DocumentListByPartRecordsGrid").jqGrid(
          {
            datatype: 'local',            
            colNames: ['<b>Id</b>', '<b>Document Name</b>', '<b>Document Type</b>', '<b>Effective Date</b>', '<b>Expiration Date</b>', '<b>Delete</b>'],
            colModel: [
                  { name: 'ASSOCIATION_ID', Index: 'ASSOCIATION_ID', resizable: true, align: 'left', hidden: true, sortable: false },
                  { name: 'FILE_NAME', Index: 'FILE_NAME', resizable: true, align: 'left', sortable: false, width:'20%' },
                  { name: 'DOCUMENT_TYPE', Index: 'DOCUMENT_TYPE', resizable: true, align: 'left', sortable: false, width:'20%' },
                  { name: 'EFFECTIVE_DATE', Index: 'EFFECTIVE_DATE', resizable: true, align: 'left', sortable: false, width:'20%' },
                  { name: 'EXPIRATION_DATE', Index: 'EXPIRATION_DATE', resizable: true, align: 'left', sortable: false, width:'20%' },
                  { name: 'Delete', Index: 'Delete',resizable: true, align: 'center', sortable: false, width:'20%' },
                  ],            
            rowNum: 15,
            rowList: [15, 50, 100],
            imgpath: '/Drm/Content/jqGrid/steel/images',
            viewrecords: true,            
            height: 162,           
            loadui: 'block',
            forceFit: true
        });

この関数で埋められます:

var mydata = '';    
<% if(!string.IsNullOrEmpty(Model.PCAssociatedDocuments)) { %>        
   var mydata = <%= Model.PCAssociatedDocuments %>;
<% } %>

for (var i = 0; i <= mydata.length; i++){
        jQuery("#DocumentListByPartRecordsGrid").addRowData(i, mydata[i], "last");
        }

これはモデルからきれいに入力されています。これは問題ではありません。この問題は、次のようにコントローラーでフォーマットされた削除機能を使用するときに発生します。

<a class='deleteAttachment' style='cursor: pointer;' href='#' onclick='javascript:PCDocumentDelete(" + s.AssociationId.ToString() + ", " + pcId + ");'>Delete</a>

この関数を呼び出します

function PCDocumentDelete(id, pcid) {
if (confirm("Are you sure you want to delete this document?")) {
    $.blockUI({
        message: "Working...",
        css: {
            background: '#e7f2f7',
            padding: 10
        }
    });
    $.ajax(
        {
            url: '/DRM/Pc/DeleteAssociation?associationId=' + id + '&pcid=' + pcid,
            async: true,
            dataType: "json",
            success: function(result) {
                if (result.Success == true) {
                    //Reload grid                       
                    $.ajax({ async: false });
                    $("#DocumentListByPartRecordsGrid").setGridParam({ url: "/Drm/Pc/DeAssociatePartRecordsWithDocument?pcid=" + pcid, datatype: 'json', myType: 'GET', page: 1 });
                    $("#DocumentListByPartRecordsGrid").trigger("reloadGrid");
                    $.unblockUI();
                    $.showGlobalMessage('Specified document has been successfully disassociated from this part record.');
                }
                else {
                    $.unblockUI();
                    $.showGlobalMessage('An error occurred deleting the attachment.');
                }
            },
            error: function(res, stat) {
                alert(res.toString());
                alert(stat.toString());
            }
        });
    return false;
}
else {
    return false;
}

}

(showGlobalMessageは、特別にフォーマットされたblockUIを作成する内部関数です)

ajaxはコントローラーでメソッドを呼び出しますが、問題はそこまで到達する前に発生するため、誰かがそれを重要だと思わない限り、そのコードを投稿するつもりはありません。何が起こるかというと、多くの場合、説明のつかない理由で、PC / DeleteAssociationを呼び出すajaxの最初のバーストが304(変更されていない)応答で戻ってきます。更新する必要のある変更が何もないときに、getで発生することを私は知っています。しかし、これは取得ではなく、投稿として扱われる必要があります。jquery.ajaxは、特に指示がない限り、304応答を生成しないように設計されているという印象を受けました。私は明らかにここで何かが欠けていて、それを自分で捕まえるにはあまりにも長い間それを見つめてきました。誰かが私が逃したものを見ますか?ありがとうございました。

4

3 に答える 3

45

わかりません。ajaxリクエストをPOSTとして指定しています。したがって、基本的に次を追加します。

$.ajax({ type: 'POST' });

それでも失敗する場合は(ブラウザのAJAXの奇妙さのため)、次のように設定してみてくださいcache: false

$.ajax({ type: 'POST', cache: false });

ところで、すべてのキャッシュ:falseは、リクエストURLにランダムなものを追加しています。

編集1:

について

...そして私はjquery.ajaxが特に指示されない限り304応答を生成しないように設計されているという印象を受けました

jQueryはここで応答を生成していません。また、304ヘッダーは単なるHTTPヘッダーです。HTTP AJAXリクエストは通常​​のHTTPリクエストであり、有効なヘッダーを返す場合があります。サーバーが304で応答する場合、XHRオブジェクトはサーバーからローカルにキャッシュされた応答を提供するだけです。ただし、ユーザーにとっては完全に透過的です。

EDIT2:

キャッシュの防止に関するアドバイスを削除しました。私にはブードゥーのようです。

EDIT3:

どうやら必要だったので、そのビットを再度追加しました。Webを見ると、IEはある程度AJAXPOSTを不正にキャッシュしているようです。

于 2011-03-31T15:10:58.110 に答える
21
  1. GETではなく、状態を変更するメソッドの呼び出しには、常にPOSTを使用してください。この場合、IEがリクエストをキャッシュするのを防ぐにはこれで十分です。
  2. IEはajaxリクエストを積極的にキャッシュします(http://www.dashbay.com/2011/05/internet-explorer-caches-ajax/およびhttps://blog.httpwatch.com/2009/08/07/ajax-caching-を参照) two-important-facts /)。これを防ぐために、次のことができます。
    1. キャッシュ無効化パラメータを追加すると、($.ajaxSetup({ cache: false });これが自動的に行われます。
    2. 常にPOSTリクエストを使用してください(ほとんどの場合、おそらく適切ではありません)。
    3. AJAXリクエストサーバー側のキャッシュヘッダーをオンにします。最初のリンクは、groovyでこれを行う方法を示しています。同様の方法をどのフレームワークにも適用する必要があります。
于 2012-04-05T01:57:21.493 に答える
1

キャッシュバスティングが解決策です!

私の場合、アプリケーションは、プロキシとしてカスタムヘッダーを使用した単一のサービス呼び出しを使用して、ブラウザーをサーバーのプライベート部分にブリッジしました(すべての呼び出しは同じURLに送信されましたが、カスタムヘッダーを使用して、プロキシサービスにどのサービスを送信するかを指示しました。に渡します)。ChromeとFFではすべて正常に機能しましたが、IEはページで行われた最初の呼び出しからデータを返し続けました。IEは呼び出されている同じURLを調べただけで、カスタムヘッダーが使用されているかどうか、または別のデータが本文に渡されているかどうかさえ調べなかったため、jQuery.ajaxのcache=falseオプションが修正されました。 「ああ、これはここで知っている。」と言って、最初の呼び出しの応答を返しました。キャッシュバスティング技術を使用すると、URLはIEとは異なって見えるため、送信されます。

于 2012-11-01T04:55:28.877 に答える