现在，我知道 URL 中的参数和 POST 参数之间的区别：如果 URL 太长，某些浏览器可能会出现异常行为，因此在 URL 中填充数百个参数不是一个好主意，即使您的应用可以响应 GET 请求。
为了便于讨论，让我们假设以下 Web 应用程序：用户可以输入一系列（可能数百个）X、Y 坐标。服务器将它们绘制在一个图表中，该图表作为图像返回。
这显然是一个idempotent operation的例子，所以，根据HTTP spec，建议实现为GET操作。但是，您无法构建包含所有参数的 URL，因为它会太长。
【问题讨论】：
HTTP specification 不明确要求将 GET 请求的参数放入 URI。在 GET 请求中发送消息体是合法的，例如使用 POST 的表单。
但是，浏览器以这种方式实现 GET 表单有一个很好的理由：缓存。 GET 请求预计将在服务器上处理而不会产生副作用。因此对 GET 请求的响应可能会被缓存。如果您开始在 GET 请求上使用消息体，则此性能改进选项会立即丢失。
如果你打算设计一个图表 API，你可能想看看Google。他们已经向公众提供了一个非常好的产品。即使只是为了学习如何将尽可能多的信息打包到 URI 参数中，也值得一看。
【讨论】：
不，服务器看不出将参数放入 URL 和使用带有 GET 方法的 FORM 之间的区别。因此，如果给定的带有参数的 URL 太长，使用带有 GET 方法的 FORM 将无济于事。
应该选择 POST 或 GET 主要是因为它们的语义。 GET 用于“安全”操作。也就是说，用户不应对 GET 请求执行的操作负责。 POST 方法用于需要用户负责的操作。
这是非常令人沮丧的，例如，当搜索功能使用 POST 时。用户不希望一个简单的查询改变任何重要的系统状态——他们希望搜索是一种“安全”的操作。
另一方面，由于不安全的操作可以通过 GET 请求以及 POST 访问，因此存在许多漏洞。这会导致 XSRF 等漏洞，其中攻击者只需将恶意“src”URL 获取到合法站点上的 IMG 标记中。
对于您的用例，Ajax 实际上可能是一个合适的解决方案。您可以为每个选定的点发出 GET 请求，将它们存储在服务器的会话中。当用户完成输入点时，最终的 GET 请求会检索完成的产品。
【讨论】：
HTTP 规范没有设置限制，但浏览器和服务器会这样做。详情请见here。
如果表单的方法设置为 GET，浏览器将创建一个长 URL，因此上述限制适用。
【讨论】：
我还听说
没错，这里是对应的RFC section
请求是否有最大长度？
spec 表示“HTTP 协议对 URI 的长度没有任何先验限制。”
但是，Internet Explorer 6 的字符数限制为 2,083 个。 其他浏览器允许更多字符，但如果你走这条路，你基本上必须为 ie6 设计
【讨论】：
这不是您有关获取和发布问题的答案，但在您所描述的情况下，将更复杂的数据存储在服务器上并将其与会话 ID 或用户帐户相关联通常更容易而不是每次都将其放入 URL 中。然后，您可以在 cookie 中仅使用该会话的标识符或作为 url 参数来检索图像。
这还可以帮助您缓存请求的图像，这样您就不必在每次用户想要再次查看特定图表时都重新生成它们。
【讨论】：
GET 和 url ?name=value&... 是一回事，因为浏览器只是在发送请求之前将 GET 表单转换为 URL。
URL 的最大长度在浏览器和服务器级别确定，因此对于给定的浏览器/服务器，它是两者中较小的一个。
This post 有一个很好的 URLS 当前最大长度列表
【讨论】：
form method=get 会将所有表单的输入放入 URL。
浏览器确实有 URL 的最大长度。它从浏览器更改为浏览器，当然也从浏览器版本更改为浏览器版本。
如果可以的话，我会建议您使用 POST 作为您的表单。
HTH
【讨论】：
您的浏览器实际上所做的是从表单输入构建一个非常长的 url。因此 URL 和表单 Method="GET" 之间没有区别。任何一个都将导致加载相同的 URL。
【讨论】：