关于HTTP的GET请求参数长度限制问题和我对中国式教育的吐槽

本文链接：https://blog.csdn.net/kwsy2008/article/details/48251157

隐隐约约记得，http的get请求的参数长度是有限制的，所以当从客户端向服务端发送数据时，如果数据量太大，那么就不要用get方法，而要用post方法。

我相信，很多人同我一样，对这个问题的认识仅仅停留在上一段文字所描述的水平内，含糊不清，似懂非懂，好像知道，但是又拿不准。我们喜欢批评中国的教育，常常列举出各种弊病，这里，我很想说，我们的教育，很失败的一个地方就是，培养了数以百万计的大学生，可数以百万计的大学生却很少有人具备科学精神。前阵子，看到一个新闻，一个老师带着学生们做实验，实验的内容就是验证温水到底能不能煮青蛙。一直以来，我们看到的各种心灵鸡汤都告诉我们，用温水煮青蛙，青蛙不会跳走，这故事告诉我们，不要安于现状，说起来真的好哲理啊，但是青蛙真的有那么傻么？这位老师带着这样的怀疑和学生们一起做实验，而实验的结果就是，水热了，青蛙就TM的跳出来了。这么多年了，对这个故事深信不疑，被这个故事少说骗了十年了，知道真相的我当时眼泪掉下来了。

愤怒羞愧之余，我也反思，这十年来，自己为啥就没有怀疑过呢，可能有过怀疑，但是为啥不做一个实验证实一下呢？因为作为中国式教育下的学生，我们只会被动的接受知识，从没有怀疑的胆量和权力。有些事情，我至今仍耿耿于怀，中学时，语文卷子上必有一篇文章让你阅读，然后出各种各样的题，这些题中，必然有一道题目，让你分析文章的中心思想，或是对某一段进行分析以阐述作者当时的所思所想。我的个天啊，用现在的话来说，太坑爹了，因为你的答案必须和老师提供的标准答案一致。而我最耿耿于怀的是，那些所谓的标准答案太他妈的扯淡了，我时常在想，作者真的是这么想的么?作者写这篇文章的时候真的像老师所分析的那样，设计了各种巧妙的情节，运用各种巧妙的手法来表达所思所想么？以我自己写作文的经历来看，你有感觉的时候，哪他妈的想那么多啊，基本上是想到哪就写到哪，文章都是一气呵成的，根本没有那么多事后诸葛亮式的分析与考虑，一次课间休息时，不知道哪根神经搭错线了，突然就想写点东西，于是伏案10分钟，那可真是文思泉涌，那可真是倚马可待，不吹牛，10分钟的文章在课堂上被当做范文朗读。但是不管你多么怀疑，多么不情愿，你都必须按照老师教给你的套路去分析文章，因为只有这样，你才能接近那个恐怕连作者自己都不未必认同的答案。

填鸭式的教育，必然导致学生缺少实证精神，缺少科学的态度。你去书店里逛一逛，重点去计算机技术区域，同样一个领域，你找一本中国人写的，再找一本外国人写的，你看过就知道了，差距究竟在哪里。差距根本不在技术，要说技术有差距，是有的，但更大的差距在于老外的书大多有着严禁认真负责的态度，他们写书更像是在做学问，而你读中国作者写的书，你明显能感觉到他在糊弄你，正因如此，才有各种各样的30天学会什么什么，30天精通什么什么，你这是在骗人，很多程序猿，终其一生都是个半吊子，更别说30天了。这里，我极力向大家建议，今后买书，一定要买图灵教育系列的，一分钱，一分货，永恒的真理。

其实，我原本是要写一篇技术贴的，但是，从第二段开始，文思泉涌了一下，就拐到了对中国式教育的吐槽，现在，还是言归正传，说说HTTP的GET请求参数的长度限制问题。

首先，我们要明确一点，HTTP协议里，并没有对GET请求的参数的长度做出任何的限制，事实上，HTTP协议对RUI的长度没有做任何的限制，协议只是规定了，如果URI太长了而服务器又处理不了的话，应该返回一个414状态码，以下是HTTP协议的原文：

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 proxyimplementations might not properly support these lengths.

上面这段出自1999年发布的RFC2616 3.2.1章节。2014年，IETF对http协议进行了更新，将RFC2616拆分为6个单独的协议说明，为了拿出更加确凿的证据，我把这六个协议也翻了出来，在RFC 7230的3.1.1章节中也有类似的表述，原文如下：

    HTTP does not place a predefined limit on the length of a request-line, as described in Section 2.5.  A server that receives a method longer than any that it implements SHOULD respond with a 501(Not Implemented) status code.  A server that receives a request-target longer than any URI it wishes to parse MUST respond with a 414 (URI Too Long) status code (see Section 6.5.12 of [RFC7231]).

新旧两个版本的HTTP协议皆给出了相同的解释，这里附上两个协议说明的地址

RFC2616 RFC7230

那么为什么，许多人和我一样，留下了HTTP的get请求的参数长度受限制的印象呢？原来是服务器和浏览器对URL长度做了限制。

以Tomcat为例，在server.xml中可以配置很多参数，其中有一个参数名为maxHttpHeaderSize，这个参数对请求头和响应头的大小做了限制，其实，也就间接限制了URL的大小。我手里的tomcat版本是7.0.55，server.xml在conf目录下，server.xml中并没有这个参数的配置，我想，可能是需要使用者自己进行配置而不是该版本发布的时候就配置好了。对于这个参数究竟是否起作用以及究竟会限制多长的URL，我并没有实际进行测试验证，以上仅仅是我查阅资料所得。

不同厂商的浏览器对URL的长度做了限制，我看了很多帖子，都说IE对URL长度的限制是2083个字符，相比于大多数程序猿已经是一种进步了，但还是不够准确，因为对于get请求，能够使用的URL长度是2048，也就是说IE的get请求最多允许发送2048个字符，但真实的情况真的是这样么？

作为程序猿，一定要有博览群书的大志向，只有这样，才不会被技术的浪潮拍死在沙滩上，作为攻城狮，还要有严禁的治学态度，不人云亦云，拿不准的时候就写程序去验证，只有这样，才不会被不经验证的善意转帖忽悠，这不是在好为人师，而是对我个人的一个警示，技术再糙，也要有攻城狮的节操。近来一段时间，看了很多不负责任的转帖，也为很多细心权威的帖子所折服，至此立志，从今以后，尽量写原创帖，若转载，事先必验证其帖子内容的有效性。

最后，我来验证，IE浏览器的get请求的URL长度到底限制到多少，咱们先来一个服务端（node.js）：

/**
 * Created by kwsy on 2015/8/15.
 */
var http = require('http')
var server = http.createServer(function(req,res){
    console.log(req.url);
    console.log(req.url.length);
}).listen(1337);

server.on('connection',function(socket){
    console.log('客户端建立连接');
})

然后，来一段URL

http://localhost:1337/sheng?test=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

受到编辑器限制，上面的url显示的有问题，sheng?和test应该是连在一起的，一共是2083个字符，复制到IE浏览器的地址栏里点击回车下图是实际运行的结果