First of all, in fact, the length of the URL is not limited in the http 1.1 protocol. Original text of the protocol:
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
<em>Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxyimplementations might not properly support these lengths.</em>
Translation:
The HTTP protocol does not impose any prior restrictions on the length of URIs. The server must be able to handle any URI of the resources they provide, and should be able to handle URIs of unlimited length. This A URL of invalid length may be generated when the client makes a request based on the GET method. If the server cannot handle the URI that is too long, the server should return the 414 status code (this status code means that the Request-URI is too long).
Note : Servers should be cautious when relying on URIs larger than 255 bytes, as some older client or proxy implementations may not support these lengths.
For details, please refer to 3.2.1
in the Agreement
Although the protocol does not explicitly limit the length of the URL, in actual implementation, the length of the URL is still limited. One is the limitation on the server side, and the other is the limitation on the browser side.
1. Server side
On the server side, mainly apache, jboss and nginx, etc., the adjustment methods I found online can be found below: Research on http request url length and request message body length (1) (server side)
1.1 nginx
Since nginx is mainly used in the current project, we emphasize its setting parameters: large_client_header_buffers
This parameter limits the size of the maximum buffer allocated by the nginx server when it accepts the header information requested by the client. That is, the maximum size of the header information that the nginx server can receive when accepting a client request at a time. This header includes not only request-line, but also the total length of the general information header, request header field, and response header field. This also limits the length of the URL to a considerable extent.
The default limit of nginx server is 4K or 8K, which is based on the hardware configuration of the server. It is generally the size of one page of memory. Currently, most of them are 4K, that is, 4096 bytes.
2. Browser side
There are many types of browsers, and their URL length restrictions are different, as follows:
| 游览器 | 最大长度（字符数） | 备注 |
| Internet Explorer | 2083 | 如果超过这个数字，提交按钮没有任何反应 |
| Firefox | 65,536 | |
| chrome | 8182 | |
| Safari | 80,000 | |
| Opera | 190,000 | |
| curl（linux下指令） | 8167 |
These data are mainly obtained through online data search, and the author has not personally verified it. But it is an indisputable fact that there are limitations. Everyone should pay special attention to it when doing development.
The first thing I thought of was to check the HTTP 1.1 protocol to see if there are any restrictions (this protocol is really smelly and long...). I was surprised to find that it turns out that the protocol does not impose length restrictions on URLs. The original words are as follows:
"The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
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."
The HTTP protocol does not place any prior restrictions on the length of URIs. Servers must be able to handle any URIs they provide resources, and should be able to handle unlimited length URIs, which are invalid lengths. The URL may be generated when the client makes a request based on the GET method. If the server cannot handle the URI that is too long, the server should return the 414 status code (this status code means that the Request-URI is too long).
Note : Servers should be cautious when relying on URIs larger than 255 bytes, as some older client or proxy implementations may not support these lengths.
So from the perspective of the http standard protocol, there is no control over the url length. Whether there is a limit to the header length needs further study on the protocol. The restrictions on the length of url and header mainly depend on the limitations of the server and client.
Then start from the server side:
I mainly looked at apache and nginx, but we are not familiar with the others
Find such a configuration option LimitRequestLine in the official apache documentation
(http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline)
From the definition, this option does not limit the length of the URL, nor the length of the header, but the length of the request-line in the http request (related definition: http://www.w3.org/ Protocols/rfc2616/rfc2616-sec5.html#sec5.1).
That is: Request-Line = Method SP Request-URI SP HTTP-Version CRLF length.
But this also limits the parameter length of GET and HEAD requests to a large extent, because GET and HEAD requests do not send the message entity (message-body) to the server. It can be said that this restriction limits the length of the url to not exceed the set value. If it is exceeded, the server will return error status code 414 (Request-URI Too Large).
So for the entire message body, is there any limit on the apache server?
Next I looked at other related parameters, and sure enough there is: LimitRequestBody
（http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestbody）
This parameter limits the maximum message size that can be accepted by http requests. The default is unlimited, but in fact this unlimited is also limited, and the maximum cannot exceed 2G.
These are some limitations of the apache server on http requests
For nginx server, there are similar parameters
large_client_header_buffers
This parameter limits the size of the maximum buffer allocated by the nginx server when it accepts the header information requested by the client. That is, the maximum size of the information that the nginx server can receive when accepting a client request at a time. This header includes not only request-line, but also the total length of the general information header, request header field, and response header field. This also limits the length of the URL to a considerable extent.
The default limit of nginx server is 4K or 8K, which is based on the hardware configuration of the server. It is generally the size of one page of memory. Currently, most of them are 4K, which is 4096 bytes.
client_header_buffer_size
(http://wiki.nginx.org/HttpCoreModule#client_header_buffer_size)
This parameter limits the size of the http header information sent from the client. This value and large_client_header_buffers also limit the size of the http request header. If one of the values is exceeded, the server will return error status code 414 (Request-URI Too Large ).
The default value of this parameter is 1K
client_max_body_size
This parameter limits the message entity size of the http request sent from the client. If it exceeds this value, the server will return error status code 413 (Request Entity Too Large). The default value of this parameter is 1MB, which is equivalent to limiting the maximum limit for content submitted through post
The above are the server-side restrictions on the http request URL length and request message body length. These are the results I only obtained based on its official documents and have not been tested in practice
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
