もっと一般的な質問です。 JSONリクエストの場合、ajaxリクエストのレスポンス・サイズに制限はありますか？ajaxリクエストブラウザの制限
大量のデータをJSONリクエストで渡していますが、FF3では 'script stack quota is exhausted'というメッセージが表示されます。今FF2ではクォータは4MBでしたが、FF3では640kbです。私はこれが何とかJSON固有のものかどうか疑問に思っています。通常のAjaxリクエストには応答サイズの制限がありますか？ブラウザによって課せられるかもしれない1つ？非JSONリクエストでスクリプトスタックのクォータで同じ問題が発生しない場合は、どのようにデータを戻すかを分類できますか？ XMLおそらく...私はそうするために私のデータでw3c仕様の範囲内にあるかどうかはわかりません。
私はあなたがデータを受け取ることとは違うと思うので、私はそれがクライアントにデータを送信することを想定しています。 JSONは単なるデータ型です。あなたが実際にやっていることは疑わしいです、合理的なサイズに制限されるはずのjavascriptスクリプトに対するGET要求を出しています。 JSON用のWikiでは、制限を超えてしまう可能性のあるXMLHTTPRequestメソッドを使用していますが、クロスドメインスクリプトの制限を回避し、html、xml、バイナリなどのより合理的なMIMEタイプを使用するにはプロキシが必要ですJSONに画像を置く場合は、これらの要求とのクロスドメインの問題がないため、リンクにすることができます。
問題を引き起こすリクエストの数ではなく、ブラウザにも制限があります。場合によっては2と低くなることがあります。
一般的に私はAJAXデータを小さく保つようにしています。私が大量のデータを渡す必要がある場合、私はそれを複数の呼び出しで取得します。だから、テーブルをロードしている場合、返されるレコードの数を示す1つのメソッドと＃（通常は20）のグループのレコードを返す別のメソッドがあります。
これを行うことの良いところは、データを取得するときにページを読み込むことができ、大きなペイロードを待つことができないことです。
また、XMLではなくJSONを使用する方がよいでしょう。 JSONは通常XMLよりもペイロードが小さく、ブラウザで読み込みが容易であることが多くのテストで分かっています。
iircこれは昨年のFF3のバグでしたが、私は（はい、それをチェックしたと思われます）here一定。しかし、コメントを見下ろすと、このノートがあります：
Note: this test is dependent upon architecture and available memory. On a x86_64 machine with 2G and a 64bit build, it will fail with InternalError: script stack space quota is exhausted however on a x86_64 with 4G and a 64bit build it will pass.
コメントも、これはデータ形式が重要で厳密ませんが、JSONの非常に大きな塊がJSスタックを吹く可能性がある意味純粋なJSの問題であることを読んでXML文字列はそうではないかもしれません。私はあなたが試してみる必要があると思う。
OTOH、それは固定とマークされているので、あなたもFFの最新バージョンを使用していることを確認する問題があります。
私は実際の制限はありませんでしたが、ユーザーのインタラクティビティは、大量のデータを複数の呼び出しに分割しています。大規模なテーブルは、特にユーザーがIEを実行している場合は、ajaxを介して転送されるために永遠にかかります。大きなデータ+ Ajax + IE = IEクラッシュ
私は真中が正しいと思います。
エラーメッセージのテキストには、json構造の深さ（KBサイズではありません）のために問題が発生していることが示唆されています。
あなたのjsonを評価すると、JavaScriptエンジンはjsonの解析中にスタックを使います。このスタックは、json構造の深さ（入れ子要素の数）のために最大限に達しています。
お客様の要件に応じて、よりフラットな構造が実現可能かどうかを確認したい場合があります。