Restrictions on the URL Length in HTTP (data sorting) and url Length

Source: Internet
Author: User
Tags nginx server

Restrictions on the URL Length in HTTP (data sorting) and url Length
URL length limit in HTTP

First, the url Length in http 1.1 is not restricted:

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 shocould be able to handle URIs of unbounded length if they provide GET-based forms that cocould generate such URIs. A server shoshould 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 proxyimplementations might not properly support these lengths.

Translation:

The HTTP protocol does not limit the URI length in advance. The server must be able to process any URIs of resources they provide and be able to process URLs of infinite length, this invalid URL may be generated when the client initiates a GET-based request. If the server cannot process a long URI, the server should return a 414 status code (this status code indicates that the Request-URI is too long ).

Note: The server should be cautious when dependent on a URI larger than 255 bytes, because some old client or proxy implementations may not support these lengths.

For more information, see 3.2.1.

Although the Protocol does not explicitly limit the url length, in actual implementation, the url length is still limited. One is the server side and the other is the browser side.

I. Server Side

On the server side, it is mainly apache, jboss, and nginx. The adjustment method I found on the Internet can be found below: Research on the http request url Length and request message body length (1) (server)

1.1 nginx

Since nginx is mainly used in the current project, the Setting Parameter large_client_header_buffers is emphasized.

This parameter limits the size of the maximum buffer allocated when the nginx Server accepts the header information of the client request, that is, the maximum size of information that the nginx server can receive when it accepts a client request at a time. This header not only contains request-line, but also the total length of common information headers, request header fields, and response header fields. This also limits the url length to a considerable extent.

The default limit of the nginx server is 4 K or 8 K. This is based on the hardware configuration of the server. Generally, the size of a page of memory is 4 K, that is, 4096 bytes.

 

2. Browser Side

There are many types of Web browsers, and the URL length restrictions are different, as shown in the following code:

Browser Maximum length (characters) Remarks
Internet Explorer 2083 If this number is exceeded, the submit button does not respond.
Firefox 65,536  
Chrome 8182  
Safari 80,000  
Opera 190,000  
Curl (commands in linux) 8167  

 

 

 

 

These data are mainly searched through online data, which has not been verified by the author. However, there are limits that do not conflict with each other. You should pay special attention to them when developing them.

 

 

The first thing I think of is to look at the HTTP 1.1 protocol and see if there are any restrictions (this protocol is really smelly and long .......). Surprised to find that the original protocol does not limit the url length. The original statement is 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 shocould be able to handle URIs of unbounded length if they provide GET-based forms that cocould generate such URIs. A server shoshould 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 lengthsAbove 255 bytes, because some older client or proxyImplementations might not properly support these lengths ."

The HTTP protocol does not limit the URI length in advance. The server must be able to process any URIs of resources they provide and be able to process URLs of infinite length, this invalid URL may be generated when the client initiates a GET-based request. If the server cannot process a long URI, the server should return a 414 status code (this status code indicates that the Request-URI is too long ).

Note: The server should be cautious when dependent on a URI larger than 255 bytes, because some old client or proxy implementations may not support these lengths.

 

Therefore, the http standard protocol does not control the url length, and whether the header length is limited is subject to further research. The limit on the url and header length mainly depends on the server and client.

 

Start with the server:

I mainly looked at apache and nginx servers, but I am not familiar with other servers.

Find this configuration option LimitRequestLine in apache official 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 head 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, the length of Request-Line = Method SP Request-uri sp http-Version CRLF.

However, this restricts the length of the GET and HEAD request parameters to a large extent, because GET and HEAD requests do not send message-body to the server. It can be said that this limit means that the url length cannot exceed the set value. If it is exceeded, the server will return an error code 414 (Request-URI Too Large ).

Is there a limit on the apache server for the entire message body?

Now I have read other related parameters, which are: 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 value is infinite, but in fact this limit is limited, and the maximum value cannot exceed 2 GB.

This is some restrictions on http requests of the apache server.

Similar parameters are available for nginx servers.

Large_client_header_buffers



This parameter limits the size of the maximum buffer allocated when the nginx Server accepts the header information of the client request, that is, the maximum information size that the nginx server can receive when it accepts a client request at a time. This header not only contains request-line, but also the total length of common information headers, request header fields, and response header fields. This also limits the url length to a considerable extent.

The default limit of the nginx server is 4 K or 8 K. This is based on the hardware configuration of the server. Generally, the size of a page of memory is 4 K, that 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 from the client. This value and large_client_header_buffers both limit the size of the http request header, if one of the values is exceeded, the server returns the error code 414 (Request-URI Too Large ).

The default value of this parameter is 1 K.

Client_max_body_size


This parameter limits the size of the message Entity in the http Request from the client. If this parameter is exceeded, the server returns the error code 413 (Request Entity Too Large ). The default value of this parameter is 1 MB, which limits the maximum size of content submitted in post mode.

 

These are the server-side restrictions on the length of the http request url and the length of the request message body. These results are only obtained according to the official documentation and have not been tested.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.