大表单搜索结果的分页技术
在网页中创建搜索表单时，我通常使用 GET 方法。这允许结果URI 可寻址。它还可以以标准方式轻松对结果进行分页。
但是如果表单具有大量选项和相当长的字段名称呢？使用 GET 请求意味着结果页面的 URL 实际上可以破解 实际 URL 长度限制为 2KB。
如果我更改为使用 POST，我就突破了 URL 长度限制。但随后我就失去了 URI 可寻址性。此外，所有分页链接都需要重新实现为小子表单，所有搜索参数数据都存储在隐藏字段中；使它们作为链接运行将需要诸如 onclick 处理程序之类的东西，这使得它们仅在启用客户端脚本时才可用。
那么，对于长搜索表单的建议是：
- 保持 URI 可寻址性
- 允许合理的分页链接
- 不要打破实际的 URL 2KB 长度限制
我唯一想到的是坚持使用 GET，但减少字段的长度名称，这样我们就不太可能突破 URL 限制。
你觉得怎么样？非常感谢。
When creating search forms in web pages, I generally use the GET method. This allow the results to be URI Addressable. It also makes for easy pagination of results in the standard manner.
But what about a form with a large number of options and fairly long field names? Using a GET request means that the URL of the results page can actually crack the practical URL length limit of 2KB.
If I change to using POST, I beat the URL length limit. But then I lose the URI addressability. Also, all pagination links need to be reimplemented as little subforms with all the search parameter data stored in hidden fields; making these operate as links would then require something like onclick handlers, which makes them usable only when client-side scripting is enabled.
So, what is the advice for long search forms that:
- maintain URI addressability
- allow reasonable pagination links
- don't break a practical URL 2KB length limit
The only thing I'm coming up with is sticking with GET, but reducing the lengths of the field names so that we are less likely to bust the URL limit.
Whaddya think? Many thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您需要做的是使用 post 方法 - 如果您的 URL 将超出限制，您将无法解决此问题（尽管您可以通过缩写名称和值来延迟不可避免的情况）。
获取帖子，然后将客户端重定向到 get，为了保持内容可寻址，您可以将搜索服务器端存储在一个密钥上并在 get 上检索它（例如从内存或数据库），或者您可以将密钥编码为单个查询字符串键或捕获行为的较少数量的键。生成的响应将可添加书签等。
分页非常简单 - 只需查找表单集合中是否存在导航按钮并做出相应响应。
What you need to do is use the post method - you can't get around this if your URL is going to be over the limit (although you can delay the inevitable by abbreviating names and values).
Take the post and then redirect the client to a get, to keep things addressable you can either store the search server side against a key and retrieve it on the get (e.g. from memory or a database), or you could encode the keys into a single querystring key or a smaller number of keys which capture the behaviour. The resulting response will be bookmarkable etc.
Pagination is easy enough - just look for the presence or absence of the navigation buttons in the form collection and respond accordingly.