为什么 GET 中的字符总数是有限的？
Why is the total amount of character in a GET limited?
我想问一些关于以下摘自 Head First Servlets 和 JSP 第二版书的引述的问题：
The total amount of characters in a GET is really limited (depending
on the server). If the user types, say, a long passage into a “search”
input box, the GET might not work.
- 为什么 GET 中的字符总数有限制？
- 如何得知一个Get中的字符总数？
当我在任何输入框中输入长文本时，GET 不起作用。
我有多少解决方案可以解决这个问题。
- 为什么get方法受限？
'get'-数据在查询字符串中发送 - 也有最大长度。
您可以使用查询字符串做各种事情，例如将其加入书签。您真的要为真正的大文本添加书签吗？
可以将大多数服务器配置为使用更大的长度 - 有些客户端会接受它们，有些会抛出错误。
"Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths." HTTP 1.1 规范第 3.2.1 章：.
还有一个状态代码“414 Request-URI Too Long”- 如果您收到此代码，您将知道您在 get 中放入了很多字符。 （如果您达到服务器限制，如果客户端限制低于服务器限制，每个浏览器将以自己的方式做出反应）。
一般来说，为发送到服务器的每个数据设置一个限制是明智的——只要有人试图产生巨大的工作量或降低服务器的速度（例如发送一个巨大的文件——使用 1 个服务器连接。慢关闭传输，进行额外的发送 - 在某些时候，服务器会打开很多连接。使用多个客户端，你就会在服务器上遇到攻击场景）。
GET 请求的长度没有具体限制。不同的服务器可以有不同的限制。如果需要向服务器发送更多数据，请使用 POST 而不是 GET。服务器和浏览器支持的建议最小值为 8,000 字节，但这不是必需的。
RFC 7230 的 Section 3.1.1 "Request Line" 说
HTTP does not place a predefined limit on the length of a request-line, as described in Section 2.5. A server that receives a method longer than any that it implements SHOULD respond with a 501 (Not Implemented) status code. A server that receives a request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code (see Section 6.5.12 of RFC7231).
Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
Section 2.5 "Conformance and Error Handling" 说
HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two decades of HTTP use and is expected to continue changing in the future.
和 RFC 7231 的 Section 6.5.12 "414 URI Too Long" 说
The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section
5.3 of [RFC7230]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of
itself) or when the server is under attack by a client attempting to
exploit potential security holes.
我想问一些关于以下摘自 Head First Servlets 和 JSP 第二版书的引述的问题：
The total amount of characters in a GET is really limited (depending on the server). If the user types, say, a long passage into a “search” input box, the GET might not work.
- 为什么 GET 中的字符总数有限制？
- 如何得知一个Get中的字符总数？
当我在任何输入框中输入长文本时，GET 不起作用。 我有多少解决方案可以解决这个问题。
- 为什么get方法受限？
'get'-数据在查询字符串中发送 - 也有最大长度。
您可以使用查询字符串做各种事情，例如将其加入书签。您真的要为真正的大文本添加书签吗？
可以将大多数服务器配置为使用更大的长度 - 有些客户端会接受它们，有些会抛出错误。
"Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths." HTTP 1.1 规范第 3.2.1 章：.
还有一个状态代码“414 Request-URI Too Long”- 如果您收到此代码，您将知道您在 get 中放入了很多字符。 （如果您达到服务器限制，如果客户端限制低于服务器限制，每个浏览器将以自己的方式做出反应）。
一般来说，为发送到服务器的每个数据设置一个限制是明智的——只要有人试图产生巨大的工作量或降低服务器的速度（例如发送一个巨大的文件——使用 1 个服务器连接。慢关闭传输，进行额外的发送 - 在某些时候，服务器会打开很多连接。使用多个客户端，你就会在服务器上遇到攻击场景）。
GET 请求的长度没有具体限制。不同的服务器可以有不同的限制。如果需要向服务器发送更多数据，请使用 POST 而不是 GET。服务器和浏览器支持的建议最小值为 8,000 字节，但这不是必需的。
RFC 7230 的 Section 3.1.1 "Request Line" 说
HTTP does not place a predefined limit on the length of a request-line, as described in Section 2.5. A server that receives a method longer than any that it implements SHOULD respond with a 501 (Not Implemented) status code. A server that receives a request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code (see Section 6.5.12 of RFC7231).
Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
Section 2.5 "Conformance and Error Handling" 说
HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past two decades of HTTP use and is expected to continue changing in the future.
和 RFC 7231 的 Section 6.5.12 "414 URI Too Long" 说
The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target (Section 5.3 of [RFC7230]) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself) or when the server is under attack by a client attempting to exploit potential security holes.