1

作業している製品のASP.NET/Castle Monorailサイトに小さな（またはそれほど小さくない）問題があります。これはかなりレガシーなシステムであり（私の時代よりかなり前に作成されました）、クエリ文字列にかなりの量の情報を含むGETリクエストを使用します。最近、クエリ文字列の長さの制限に遭遇しました。サーバーに転送する必要のあるデータの量については、データを一時的にCookieに保存することも妥当ではありません（Cookieあたりの4096バイトの制限をすでにはるかに超えています。多くのCookieを設定するため、ドメインごとのCookieの制限に近いか、制限に達している可能性があります。）

POST以外に（場合によってはPOSTリクエストに変更できる場合もありますが、すべてではない可能性があります）、この問題を解決できる代替手段があるかどうか疑問に思っています。StackOverflowの他の誰かが同様の問題に遭遇し、いくつかの魔法の解決策があることを願っています（つまり、javascriptでデータを圧縮し、base64としてエンコードし、単一のクエリ文字列アイテムに渡しますか？圧縮できるライブラリがあるかどうかはわかりません.NET 3.5の組み込み圧縮クラスと互換性のある方法でJavaScriptを使用したデータ。）

アップデート：

私が選んだ解決策は、一時的なコントローラーにPOSTすることでした。この一時コントローラーは、大量のデータのリストをプルし、共有セッションにスタックし（本番サーバーは、スティッキーセッション/ IPを使用しない大規模なマルチバンクサーバーファームにあります）、実際のコントローラーに対してGETを実行しました。共有セッションからのデータ。最もパフォーマンスの高いソリューションではありませんが、問題は解決しました。

4

7 に答える 7

3

There are several Base64 encode plugins for jQuery, but that doesn't help because Base64 generally makes the data longer, not shorter.

Depending on the data, I'd look at some other text compression techniques. Wikipedia lists a few:

  • Context Tree Weighting method (CTW)
  • Burrows-Wheeler transform (block sorting preprocessing that makes compression more efficient)
  • LZ77 (used by DEFLATE)
  • LZW

Here's an LZW implementation for Javascript.

Huffman encoding is based on letter frequency, so it might not be appropriate for your data. You'll probably have to escape the result to make it URL-safe.

于 2009-07-28T16:19:29.577 に答える
1

POST に切り替える以外に、オプションは制限されます。Base64 は、データのサイズを減少させるのではなく、増加させようとしています。データを単一のクエリ文字列アイテムに圧縮することに言及しています...代わりに、Ajaxを使用してデータを2つの別々のリクエストに分割できますか? ただし、それがあなたの状況に適しているかどうかはわかりません。

于 2009-07-28T16:12:31.103 に答える
1

クエリ文字列のような配列が次のように生成される場合は、JSON をデータ転送形式として使用することをお勧めします。

params[]=sth&params[]=sth2&params[]=sth3

これは

{params:['sth1', 'sth2', 'sth3']}

以下のように、この JSON 文字列を 1 文字の変数に割り当てることができます。

p={params:['sth1', 'sth2', 'sth3']}

さらに良いのは、クエリ文字列全体を圧縮して Base64 エンコードすることです。サーバー側でクエリ文字列を生成するため（これは同じですが、同じcomp/decompアルゴリズムを使用してJSで実行できると思います）、gzipなどのプログラミング言語で組み込みの圧縮アルゴリズムを使用できます。圧縮されたデータを Base64 でエンコードした後、はい、少し拡張されますが、URL エンコードが拡張するほどではありません。

于 2009-07-28T18:00:35.940 に答える
0

I would not rely too much on javascript. Compacting the query string would be the first natural thing to do; but if you're way ahead those limits, you should try mentaining sessions. You start up fresh with default state info, then gradually reflect the state on the server into the user's session with POST data provided, so you partition all that data into many handlers (read pages).

于 2009-07-28T16:17:24.447 に答える
0

教科書的な答えは、POST を使用することです。なぜこれが不可能なのですか？POST が発明された理由は、GET での長さの制限を回避するためでした。

詳細に応じた別の可能性は、それぞれがデータのサブセットを持つ複数の画面を持ち、それぞれのデータをサーバーに保存し、最後にそれらを接続することです。

于 2009-07-28T16:52:51.117 に答える
0

クエリ文字列の制限はクライアントまたはサーバーにありますか?

問題がクライアントが長い GET 文字列を送信しないということだけである場合は、プロキシ サーバーに POST して、要求を GET として転送することができます。

于 2009-07-28T16:56:06.817 に答える
0

これは、ページ間で状態情報を保持するためですか? その場合、オプションは、その値として GUID を持つ Cookie を使用することです。

_SESSIONID=3F2504E0-4F89-11D3-9A0C-0305E82C3301

セッション情報をサーバー側に保存します。セッションは GUID で一意に識別されるため、大量の情報をサーバー上で直接簡単に取得できます。

クライアント側で送信/取得する必要があるのは、そのセッション ID と、クライアントが生成した情報 ( GET/POSTフィールド) だけです。

于 2009-07-28T17:03:10.440 に答える