这个问题一直以来似乎是被N多人误解，其实Http Get方法提交的数据大小长度并没有限制，而是IE浏览器本身对地址栏URL长度有最大长度限制：2048个字符。
当您从 WinInet 应用程序到 Web 服务器发送一个长的查询字符串时，查询字符串可能会被截断。
出现此问题是由于中 WinInet，定义 Wininet.h 文件中，如下所示的 URL 的长度限制：
#define INTERNET_MAX_PATH_LENGTH 2048
#define INTERNET_MAX_SCHEME_LENGTH 32 // longest protocol name length
#define INTERNET_MAX_URL_LENGTH (INTERNET_MAX_SCHEME_LENGTH + sizeof("://") + INTERNET_MAX_PATH_LENGTH)
此行为是设计使然
注意： 因为 Internet Explorer 和 Internet 传输的控制也使用 WinInet，可能会出现相同的问题。
若要解决此问题，使用 HTTP POST 方法。
http://support.microsoft.com/kb/208427/zh-cn
Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs. ‘>以下附上微软官方的一段说明：
Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs. ‘>Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs.
If you are using the GET method, you are limited to a maximum of 2,048 characters, minus the number of characters in the actual path.
However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL. ‘>However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.
RFC 2616, “Hypertext Transfer Protocol — HTTP/1.1,” does not specify any requirement for URL length.
其他文章内容摘要：
最近一直在做Web相关的项目，熟悉Web开发的人都知道，我们经常需要通过URL来传递参数，即所谓的“GET”方法，还有一种是“POST”，两种方法都用的很多。其中，GET方法适合参数数据量比较小的情况，GET方法比较直观，通过URL就能大概知道回传了哪些参数。POST适合向服务器回传大量的数据，没有GET方法直观。以前我大概看过，通过URL回传参数有个长度限制，当时我看的是1024字节，由于以前做的项目，参数较少，基本不可能超过1024，所以我也没有仔细研究过到底是不是1024字节。最近这个项目，由于参数较多，已经超过1024了，显然我要考虑URL能够接收的最大长度了，在网上搜了一下，得到了准确答案：HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。[参考http://support.microsoft.com/kb/q208427/]。我这就放心，2083字节应该是够用了，呵呵。至于POST方法，可以参考如下这篇文章的介绍。
表单Post&Get两个长度限制问题的分析
引用地址：http://phoubes.bokee.com/5488853.html
一、问题起因
在某项目释放后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等，理论上没有长度限制，其限制取决于操作系统的支持。
3）“可变长度的参数通过URL方式传递”实际是说提交表单时使用了GET方法，而不是POST方法。造成这种潜在错误的是使用GET方法提交表单数据。因为GET方法将数据放在URL里传递给服务器处理。
4）注意这个限制是整个URL长度，而不仅仅是你的参数值数据长度。
5）既然是IE对URL长度的限制，那么不管是GET方法还是POST方法都存在这个限制。
建议：
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表单域数据的解决办法，请参考后面的。
4）由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制。我们还需要注意：
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。
