URL length limit in HTTP (data pack)

Source: Internet
Author: User
Tags error status code nginx server
URL length restrictions in HTTP (data collation)

URL length limit in HTTP

First of all, in fact the HTTP 1.1 protocol to the length of the URL is unrestricted, the original protocol:

The HTTP protocol does not place any a priori limit on the length of a URI. Servers must is able to handle the URI of any resource they serve, and should is able to handle URIs of unbounded length I F 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.1 5).

  Note:servers ought to being cautious about depending on URI lengths above 255 bytes, because some older client or proxyimple Mentations might not properly support these lengths.

Translation:

The HTTP protocol does not limit the length of the URI, the server must be able to handle any URI that they provide, and it should be able to handle an infinite length of URIs, a URL that is invalid in length that may be on the client Generated when a Get method is requested. If the server cannot handle too long a URI, the server should return a 414 status code (this status code represents Request-uri too long).

Note : Servers should be cautious when relying on URIs that are larger than 255 bytes , because some old customer or proxy implementations may not support these lengths.

See 3.2.1 in the Agreement

Although the protocol does not explicitly limit the length of the URL, but in the real implementation, the length of the URL is still limited, one is the server-side restrictions, and the other is the browser-side restrictions.

One, server-side

On the server side, mainly Apache,jboss and nginx, I found on the Internet adjustment method can participate in the following: about the HTTP request URL length and the request message body length research (a) (server side)

1.1 Nginx

Since the main use of Nginx in the project now, so emphasize its setting parameters: Large_client_header_buffers

This parameter restricts the size of the maximum buffer allocated when the Nginx server accepts the header information requested by the client, which is the maximum size of the header information that the Nginx server accepts for one client request at a time. This header includes not only the request-line, but also the general information header, the Request header field, and the length sum of the response header fields. This also limits the length of the URL to a considerable extent.

Nginx Server default limit is 4K or 8K, which is based on the hardware configuration of the server, usually the size of the memory page, the majority of the current is 4K, that is, 4096 bytes.

Second, the Tour terminal

There are a variety of browser types, and the length limit for URLs is different, as follows:

Tour Viewer Maximum length (number of characters) Note
Internet Explorer 2083 If this number is exceeded, the submit button has no response
Firefox 65,536
Chrome 8182
Safari 80,000
Opera 190,000
Curl (under Linux instructions) 8167

These data are mainly through the online data search, the author has not personally verified. But there are limitations are indisputable facts, everyone in the development of special attention.

The first thing I think about is to see the HTTP 1.1 protocol, see if there is a limit (this agreement is really smelly and long ...). )。 Surprised to find that the original protocol to the URL is not to do the length limit. The exact words are as follows:

TheHTTP protocol does not place any a priori limit on the length of a URI. Servers must is able to handle the URI of any resource they serve, and should is able to handle URIs of unbounded length I F 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.1 5).

Note:servers ought to being 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 limit the length of the URI, the server must be able to handle any URI that they provide, and it should be able to handle an infinite length of URIs, a URL that is invalid in length that may be on the client Generated when a Get method is requested. If the server cannot handle too long a URI, the server should return a 414 status code (this status code represents Request-uri too long).

Note : Servers should be cautious when relying on URIs that are larger than 255 bytes , because some old customer or proxy implementations may not support these lengths.

So from the HTTP standard protocol does not control the length of the URL, header length is limited tofurther study protocol. The limit on the URL and header length depends primarily on the server and the client's limitations.

Then start with the server side:

The main look at the Apache and nginx two kinds of servers, the other we are not familiar

Find such a configuration option in Apache's official documentation Limitrequestline


(Http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestline)

From the definition, this option restricts not 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: Request-line = the length of Method sp Request-uri sp http-version CRLF.

However, this will largely limit the length of the parameters for get and head requests because the get and head requests do not send the message entity (Message-body) to the server. It can be said that the limit is limited to the length of the URL can not exceed the value of the setting, if exceeded, the server will return error status code 414 (Request-uri Too Large).

Is there a limit to the Apache server for the entire message body?

Then I looked at the other relevant parameters, sure enough: 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, which is infinitely large by default, but in fact this infinity is limited and cannot exceed 2G.

This is some of the restrictions that Apache server has about HTTP requests

For nginx servers, there are similar parameters

Large_client_header_buffers



This parameter restricts the size of the maximum buffer allocated when the Nginx server accepts the header information requested by the client, that is, the maximum information size that the Nginx server accepts for one client request at a time. This header includes not only the request-line, but also the general information header, the Request header field, and the length sum of the response header fields. This also limits the length of the URL to a considerable extent.

Nginx Server default limit is 4K or 8K, which is based on the hardware configuration of the server, usually the size of the memory page, the majority of the current is 4K, that is, 4096 bytes.

Client_header_buffer_size


(http://wiki.nginx.org/HttpCoreModule#client_header_buffer_size)

This parameter restricts the size of the HTTP header information originating from the client, which limits the size of the HTTP request header, and the server returns an error status code 414 (Request-uri Too large_client_header_buffers). Large).

The default value for this parameter is 1K

Client_max_body_size


This parameter limits the message entity size for HTTP requests originating from the client, and if this value is exceeded, the server returns an error status code 413 (Request entity Too Large). The default value for this parameter is 1MB, which is equivalent to the maximum limit for post-submission content

These are the server-side restrictions on the length of the HTTP request URL and the length of the request message, which I have only obtained from the official documentation, without actual testing

  • 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.