URL中的参数和
现在，我知道 URL 中的参数和 POST 参数之间的区别：如果 URL 太长，某些浏览器可能会出现错误，因此在 URL 中填充数百个参数并不是一个好主意，即使您的应用程序可以响应一个 GET 请求。
为了便于讨论，我们假设以下 Web 应用程序：用户可以输入一系列（可能是数百个）X,Y 坐标。 服务器将它们绘制在图表中，该图表作为图像返回。
这显然是幂等操作的示例，因此，根据HTTP规范，建议实现为GET操作。 但是，您无法构建包含所有参数的 URL，因为它会太长。
我还听说过
Now, I know a difference between parameters in a URL and a POST parameter: some browsers may misbehave if the URL is too long, so it is not a good idea to stuff hundreds of parameters in a URL, even if your app can respond to a GET request.
For the sake of discussion, let's suppose the following web application: a user can input a series of (possibly hundreds of) X,Y coordinates. The server plots them in a chart, which is returned as an image.
This is clearly an example of an idempotent operation, so, according to the HTTP spec, it is recommended to be implemented as a GET operation. However, you can't build a URL with all the parameters, as it will be too long. Can a <form method="get"> handle that much parameters ?
I've also heard that <form method="get"> is completely equivalent to placing parameters in a URL ? Now, is that true for some browsers or for the whole HTTP protocol ? Is there a maximum length to a request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
HTTP 规范没有设置限制，但浏览器和服务器设置了限制。 有关详细信息，请参阅此处。
如果表单的方法设置为 GET，浏览器将创建一个长 URL，因此上述限制适用。
The HTTP spec does not set limitations, but the browsers and servers do. See here for specifics.
The browser will create a long URL if the method is set to GET for a form, so the above limitations apply.
HTTP 规范没有明确要求将 GET 请求的参数放入URI。 在 GET 请求中发送消息正文是合法的，就像使用 POST 的表单一样。
然而，浏览器以这种方式实现 GET 表单有一个很好的理由：缓存。
GET 请求预计将在服务器上处理，不会产生副作用。 因此，对 GET 请求的响应可能会被缓存。 如果您开始在 GET 请求上使用消息正文，则此性能改进选项将立即丢失。
如果您计划设计图表 API，您可能需要查看 Google。 他们已经向公众提供了一个非常好的产品。 即使只是为了学习如何将尽可能多的信息打包到 URI 参数中，它也值得一看。
The HTTP specification does not explcitely require to place parameters of a GET request into the URI. It would be legal to send a message-body in a GET request like forms using POST do.
However, browsers implement GET forms this way for a very good reason: Caching.
GET requests are expected to be processed on the server without side-effects. So responses to GET requests might be cached. This perfomance improvement option is instantly lost if you would start using message-bodies on GET requests.
If you plan to design a chart API, you may want to have a look at Google. They already offer a very good one to the public. Even if it's only for learning how to pack as many information into URI params as possible, it's worth a look.
您的浏览器实际上所做的是根据表单输入构建一个非常长的网址。 因此，URL 和 Method="GET" 形式之间没有区别。 任何一种都会导致加载相同的 URL。
What your browser actually does is build a really long url from the form inputs. Therefore there will be no difference between a URL and form Method="GET". Either one will result in the same URL being loaded.
form method=get 会将所有表单输入放入 URL 中。
浏览器确实对 URL 的最大长度有限制。 它随着浏览器的不同而变化，当然也随着浏览器版本的不同而变化。
如果可以的话，我建议您对表单使用 POST。
华泰
form method=get WILL put all the form's input into the URL.
It's true that browsers have a maximum length for the URL. It changes from browsers to browsers, and surely from Browsers version to browsers version.
If you can, I would recommend you to use POST for your form.
HTH
GET 和 url ?name=value&... 是同一件事，因为浏览器只是在发送请求之前将 GET 形式转换为 URL。
URL 的最大长度由浏览器和服务器级别确定，因此，对于给定的浏览器/服务器，它是两者中较小的一个。
这篇文章列出了当前 URL 最大长度
GET and url ?name=value&... are the same thing, as the browser merely converts a GET form to a URL before sending the request.
The maximum length of the URL is determined at the browser and server level so, for a given browser/server, it's the smaller of the two.
This post has a good list of current max lengths for URLS
不，服务器看不到将参数放入 URL 和使用带有 GET 方法的 FORM 之间的区别。 因此，如果给定的带有参数的 URL 太长，那么使用带有 GET 方法的 FORM 将无济于事。
选择 POST 或 GET 主要是因为它们的语义。 GET 用于“安全”操作。 也就是说，用户不应对 GET 请求执行的操作负责。 POST 方法用于需要用户负责的操作。
例如，当搜索功能使用 POST 时，这非常令人沮丧。 用户并不期望简单的查询能够改变任何重要的系统状态——他们期望搜索是一个“安全”的操作。
另一方面，由于可以通过 GET 请求以及 POST 访问不安全的操作，因此存在许多漏洞。 这会导致 XSRF 等漏洞，攻击者只需将恶意“src”URL 获取到合法站点上的 IMG 标记中即可。
对于您的用例，Ajax 实际上可能是一个合适的解决方案。 您可以对每个选定的点发出 GET 请求，将它们存储在服务器的会话中。 当用户输入完分数后，最终的 GET 请求将检索成品。
No, a server cannot see a difference between putting parameters in a URL and using a FORM with a GET method. So, if a given URL with parameters would be too long, using a FORM with a GET method won't help.
POST or GET should be chosen mainly for their semantics. GET is for "safe" actions. That is, users should not be held accountable for an operation performed by a GET request. The POST method is used for operations for which the user is to be held responsible.
It's very frustrating, for example, when a search feature uses POST. A user doesn't expect a simple query to alter any important system state—they expect searching to be a "safe" operation.
On the other hand, many vulnerabilities exist because unsafe operations are accessible through GET requests, as well as POST. This contributes to vulnerabilities like XSRF where an attacker simply needs to get a malicious "src" URL into an IMG tag on a legitimate site.
For your use case, Ajax may actually be an appropriate solution. You could make a GET request for each point selected, storing them in a session at the server. When the user is finished entering points, a final GET request retrieves the finished product.
这不是您关于 get 和 post 的问题的答案，但在您所描述的情况下，通常更容易将更复杂的数据存储在服务器上并将其与会话 ID 或用户帐户关联，而不是放置它每次都输入 URL。 然后，您可以仅使用 cookie 中该会话的标识符或作为 url 参数来检索图像。
这还可以帮助您缓存请求的图像，这样您就不必在每次用户想要再次查看特定图表时重新生成它们。
This isn't an answer to your question about get and post but in a situation like you are describing it is quite often easier to store the more complex data on the server and associate it with a session id or a user account rather than putting it into the URL every time. Then you can use just the identifier for that session in a cookie or as a url parameter to retrieve the image.
That can also help you to cache the requested images so you don't have to go through the work of regenerating them every time a user wants to look at a particular chart again.
确实如此，这是相应的 RFC 部分
规范说“HTTP协议不放置对 URI 长度的任何先验限制。”
但是 Internet Explorer 6 的字符数限制为 2,083 个。
其他浏览器允许更多字符，但如果你走这条路，你基本上必须为 ie6 进行设计
That's true, here is the corresponding RFC section
The spec says "The HTTP protocol does not place any a priori limit on the length of a URI."
However internet explorer 6 has a limit of 2,083 characters.
Other browsers allow more characters but if you go that route you will basically have to design for ie6