2008-06-04

XMLHttpRequest中url的长度限制的解决方法

关键字: xmlhttprequest ajax post get send

在原来的处理过程中，把ajax请求的url连请求的参数，都合成一个url，发送给后台，但是当请求的参数数据量大的时候，就出现了问题。因为URL有长度限制。

 

解决方式：POST的URL有长度限制 ， 但是数据没有... 所以你应该在send()里面发送你的数据。

 

相关的说明

=======================================================================

  1. get,post数据长度的限制

这个问题在我的开发中也遇到，所以在此贴出来(也是在网上搜出来的，呵呵)
这是原贴地址http://blog.csdn.net/somat/archive/2004/10/29/158707.aspx
两个长度限制问题的分析(来源于项目)
一、问题起因
在某项目释放后Bug统计的附件《释放后问题》里有：  
问题  原因  分析  备注 
CSV处理时，如果处理的主题数过多，发生URL参数上限的错误；  可变长度的参数通过URL方式传递，会造成这种潜在的错误发生。  1、属于2次发生问题，开发方面没有及时通过checklist等方式向组员传达相关注意事项；
2、测试时没有作大批量数据的测试；  1、作为经验添加至CheckList中，加强组内共享、检查的效果；
2、加强测试点是否完备的检查，重点关注对开发方面共性问题的测试； 
通过对模块原有GUI状况确认，进行CSV输出时，输出结果很大的场合，CSV文件的内容不能输出。  没有考虑到POST数据量存在128K的大小限制。  这属于新问题，以前从未遇见过，也没有进行过大规模的数据量测试  已将此类检查列出CheckList中 

做为一种经验积累，这些问题、原因及解决办法将被列入Checklist，那么：
第一个问题：URL参数上限的提法准确吗？上限是多少？
第二个问题：为什么POST时数据有限制？限制是128K吗？ 
二、问题分析
1、第一个：
1）URL不存在参数上限的说法。该问题实际是IE对URL有长度限制的问题。
2）HTTP协议规范也没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。[参1]
3）“可变长度的参数通过URL方式传递”实际是说提交表单时使用了GET方法，而不是POST方法。造成这种潜在错误的是使用GET方法提交表单数据。因为GET方法将数据放在URL里传递给服务器处理。
4）注意这个限制是整个URL长度，而不仅仅是你的参数值数据长度。
5）既然是IE对URL长度的限制，那么不管是GET方法还是POST方法都存在这个限制。
(关于FORM的GET和POST方法具体内容请参考相关资料[参2]) 
建议：
1）了解应用程序所在的环境，如Web应用的浏览器、服务器环境，了解其特定的参数限制情况。
2）提交复杂数据尽量使用POST方法。注意FORM不写method属性时默认是使用GET方法。
结论(写入Checklist)：
对使用GET方法提交数据时，在IE环境下，需要考虑URL长度2083字节的限制。
2、第二个：
1）理论上讲，POST是没有大小限制的。HTTP协议规范也没有进行大小限制。
2）“POST数据量存在128K的大小限制”不够准确，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。
3）对于ASP程序，Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个限制。对于需要处理超过100K表单域数据的解决办法，请参考后面的[参3]。
4）由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制[参4]。我们还需要注意：
    IIS 6.0默认ASP POST数据量最大为200KB，每个表单域限制是100KB。
    IIS 6.0默认上传文件的最大大小是4MB。
    IIS 6.0默认最大请求头是16KB。
    IIS 6.0之前没有这些限制。
建议：
1）弄清楚运行环境的默认设定值有助于你的设计及对出现的问题做快速的解决。
2）应该考虑服务器版本。各个版本的IIS对这些参数的默认设定都不一样，有必要的话，找资料整理出一份对照表。这样开发与测试时都有个参考。
3）IIS 6.0的这些限制实际只是它的默认设定值而已，实际应用环境你可以修改它们。
    在WINNT\system32\inetsrv\MetaBase.xml里默认定义了：
        AspBufferingLimit="4194304"           对应于上传文件最大大小
        AspMaxRequestEntityAllowed="204800"    对应于POST最大数据量
结论(写入Checklist)：
使用ASP时，需要考虑POST表单每个域一般读取处理时有100KB的限制。充分考虑是否使用Request.Binary

 

==========================================================================================

WWW FAQs: What is the maximum length of a URL?

2006-10-13: Although the specification of the HTTP protocol does not specify any maximum length, practical limits are imposed by web browser and server software.

Microsoft Internet Explorer (Browser)

Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer.

Firefox (Browser)

After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters.

Safari (Browser)

At least 80,000 characters will work. I stopped testing after 80,000 characters.

Opera (Browser)

At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters.

Apache (Server)

My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a "413 Entity Too Large" error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request.

Microsoft Internet Information Server

The default limit is 16,384 characters (yes, Microsoft's web server accepts longer URLs than Microsoft's web browser). This is configurable.

Perl HTTP::Daemon (Server)

Up to 8,000 bytes will work. Those constructing web application servers with Perl's HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16x1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks.

Recommendations

Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Don't use them if you intend your site to work for the majority of Internet users.

When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method: 

<form action="myscript.php" method="POST">
...
</form>
The form fields are then transmitted as part of the HTTP transaction header, not as part of the URL, and are not subject to the URL length limit. Short-lived information should not be stored in URLs.

As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL.

The Bookmark Problem

In very rare cases, it may be useful to keep a large amount of "state" information in a URL. For instance, users of a map-navigating website might wish to add the currently displayed map to their "bookmarks" or "favorites" list and return later. If you must do this and your URLs are approaching 2,000 characters in length, keep your representation of the information as compact as you can, squeezing out as much "air" as possible. If your field names take up too much space, use a fixed field order instead. Squeeze out any field that doesn't really need to be bookmarked. And avoid large decimal numbers - use only as much accuracy as you must, and consider a base-64 representation using letters and digits (I didn't say this was easy).

In extreme cases, consider using the gzip algorithm to compress your pretty but excessively long URL. Then reencode that binary data in base64 using only characters that are legal in URLs. This can yield a 3-4x space gain, at the cost of some CPU time when you unzip the URL again on the next visit. Again, I never said it was easy!

An alternative is to store the state information in a file or a database. Then you can store only the identifier needed to look up that information again in the URL. The disadvantage here is that you will have many state files or database records. Some of which might be linked to on websites run by others. One solution to this problem is to delete the state files or database records for the URLs that have not been revisited after a certain amount of time.

"What happens if the URL is too long for the server?"

What exactly happens if a browser that supports very long URLs (such as Firefox) submits a long URL to a web server that does not support very long URLs (such as a standard build of Apache)?

The answer: nothing dramatic. Apache responds with a "413 Entity Too Large" error, and the request fails.

This response is preferable to cutting the URL short, because the results of cutting the URL short are unpredictable. What would that mean to the web application? It varies. So it's better for the request to fail.

In the bad old days, some web servers and web browsers failed to truncate or ignore long URLs, resulting in dangerous "buffer overflow" situations. These could be used to insert executable code where it didn't belong... resulting in a security hole that could be exploited to do bad things.

These days, the major browsers and servers are secure against such obvious attacks - although more subtle security flaws are often discovered (and, usually, promptly fixed).

While it's true that modern servers are themselves well-secured against long URLs, there are still badly written CGI programs out there. Those who write CGI programs in C and other low-level languages must take responsibility for paying close attention to potential buffer overflows. The CGIC library can help with this.

In any case, if you're a web developer and you're still asking this question, then you probably haven't paid attention to my advice about how to avoid the problem completely.

 

评论
发表评论

您还没有登录，请登录后发表评论