将数据发送到服务器时查询字符串和 cookie 的替代方案？
对于我所从事的产品，我在某些 ASP.NET/Castle Monorail 站点上遇到了一个小（或者可能不那么小）问题。 这是一个相当遗留的系统（早在我的时代之前就已编写），它使用 GET 请求，并在查询字符串中包含大量信息。 我们最近遇到了查询字符串长度限制，并且对于我们需要传输到服务器的数据量，将数据临时存储在 cookie 中也是不合理的（我们已经远远超过了每个 cookie 4096 字节的限制，并且我们设置很多 cookie，因此我们可能也接近或达到每个域 cookie 的限制。）
我想知道除了 POST 之外是否还有其他选择（在某些情况下更改为 POST 请求可能是可能的，但可能不会）总之），这可能会解决这个问题。 我希望 StackOverflow 上的其他人也遇到了类似的问题，并且有一些神奇的解决方案（即使用 javascript 压缩数据，编码为 base64，传递给单个查询字符串项？只是不确定是否有任何可以压缩的库以与 .NET 3.5 中内置压缩类兼容的方式使用 javascript 处理数据。）
更新：
我最终选择的解决方案是 POST 到临时控制器。 该临时控制器拉取大量数据，将其固定在共享会话中（生产服务器位于不使用粘性会话/IP 的大型多银行服务器场中），并对实际控制器执行 GET，从而拉取来自共享会话的数据。 这不是最高效的解决方案，但它解决了问题。
I have a small (or perhaps not so small) issue with some ASP.NET/Castle Monorail sites for a product I work on. This is a fairly legacy system (written well before my time), and it uses GET requests with a considerable amount of information in the query string. We have recently run into query string length limitations, and for the amount of data we need to transfer to the server, storing the data temporarily in a cookie is also not plausible (we are already well past the 4096 byte limit per cookie, and we set a lot of cookies, so we are likely near or at the limit of cookies per domain as well.)
I am wondering if there are any alternatives, besides POST (in some cases changing to a POST request may be possible, but likely not in all), that might solve this problem. I'm hoping someone else here on StackOverflow has run into similar issues, and has some wizardly solution (i.e. compress data with javascript, encode as base64, pass to a single query string item? Just not sure if there are any libraries that can compress data with javascript in a way compatible with built-in compression classes in .NET 3.5.)
UPDATE:
Solution I ended up choosing was to POST to a temporary controller. This temp controller pulled the large list of data, stuck it in a shared Session (the production servers are in a large multi-bank server farm that does not use sticky sessions/IPs), and performed a GET to the actual controller, which pulled the data from the shared Session. Not the most performant solution, but it solved the problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
有几个 jQuery 的 Base64 编码插件，但这并不有帮助，因为 Base64 通常会使数据更长，而不是更短。
根据数据，我会研究一些其他文本压缩技术。 Wikipedia 列出了一些：
这是一个 LZW JavaScript 的实现。
霍夫曼编码 基于字母频率，因此它可能不适合您的数据。 您可能必须对结果进行转义以使其成为 URL 安全的。
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:
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.
除了切换到 POST 之外，您的选择将受到限制。 Base64 会增加数据大小而不是减少数据大小。 您提到将数据压缩为单个查询字符串项...也许您可以使用 Ajax 将数据拆分为 2 个单独的请求？ 不过，我不确定这对于您的情况是否可行。
Beyond switching to POST your options are going to be limited. Base64 is going to increase the size of the data not decrease it. You mention compressing the data into a single query string item... maybe instead you could split the data into 2 separate requests using Ajax? I'm not sure if that's feasible for your situation, though.
如果生成类似数组的查询字符串，我建议使用 JSON 作为数据传输格式，如下所示：
更好
您可以将此 JSON 字符串签名为单个字母变量，如下所示
的方法是压缩整个查询字符串并进行 Base64 编码。 由于您在服务器端生成查询字符串（我假设通过使用相同的压缩/解压缩算法可以在 JS 中完成相同的操作），因此您可以在编程语言中使用任何内置压缩算法，例如 gzip。 对压缩数据进行 Base64 编码后，是的，它会扩展一点，但不会像 url 编码扩展的那么大。
I would suggest using JSON as the data transfer format if an array like query string is generated as follows:
This would be
You can sssign this JSON string to a single letter variable like below
Something even better would be compressing and Base64 encoding the whole query string. Since you generate the query string on the server side(I assume this but same thing can be done in JS by using the same comp/decomp algorithms) you can use any builtin compression algorithm with your programming language such as gzip. After Base64 encoding the compressed data, yes it will expand a bit but not as much as url encoding expands it.
我不会太依赖javascript。 压缩查询字符串将是第一个自然要做的事情； 但如果你远远超出了这些限制，你应该尝试维持会议。 您从默认状态信息开始，然后使用提供的 POST 数据逐渐将服务器上的状态反映到用户会话中，因此您将所有这些数据划分到许多处理程序（读取页面）中。
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).
教科书的答案是使用POST。 为什么这不可能呢？ 发明 POST 的原因很大程度上是为了绕过 GET 的长度限制。
另一种可能性取决于细节，即拥有多个屏幕，每个屏幕都有数据的子集，并将每个屏幕的数据存储在服务器上，最后将它们连接起来。
The textbook answer is to use POST. Why would this not be possible? The reason POST was invented was pretty much to get around length limits in GET.
Another possibility depending on the details is to have multiple screens, each with a subset of the data, and store the data from each on the server and connect them up at the end.
查询字符串限制是在客户端还是服务器端？
如果问题只是客户端不会发送长 GET 字符串，也许您可以 POST 到代理服务器，然后代理服务器将请求作为 GET 转发。
Is the query string limitation on the client or the server?
If the issue is just that the client will not send the long GET string, perhaps you can POST to a proxy server which then forwards the request as a GET.
这是为了保存页面之间的状态信息吗？ 如果是这样，一个选项可能是使用具有 GUID 值的 cookie，如下所示：
并将会话信息存储在服务器端。 会话由 GUID 唯一标识，因此可以轻松地直接在服务器上检索大量信息。
然后，您需要发送/检索客户端的是会话 ID 以及客户端生成的信息（
GET/POST字段）。Is this to hold state information between pages? If so, an option could be to use a cookie with it's value a GUID as such:
And store the session information server-side. The session is uniquely identified with a GUID, so it is then easy to retrieve the large amount of information directly on the server.
All you then need to send/retrieve client-side is that session id, as well as client generated information (
GET/POSTfields).