今天又遇到了这个问题,以前其实是知道的。IE下的cookie长度和firefox下不一样。GET的长度也不样。
但我在记忆中一直是当成4096来处理的。看来我脑子里想的更多的都是firefox或者chrome,今天遇到某些信息不能显示的时候,又想起这个问题。才发现:
原文:http://blog.csdn.net/tuwen/article/details/5257154
看见很多朋友讨论浏览器最大URL长度限制的问题。其实实际中URL长度限制是由2方面决定的。1 客户浏览器 2 接受服务请求的服务器端的设置。对于大多数用户来说,他们使用的浏览器是IE浏览器,IE的最大URL长度限制是2083字节,而实际可以使用的最大长度 为2048字节。
以下是微软方面的技术资料及翻译:
Maximum URL length is 2,083 characters in Internet Explorer
在IE中URL最大长度是2083字节
SUMMARY
摘要
Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters.
微软 Internet Explorer 限制最大统 一资源定位器 (URL) 长度为2083字节。
Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST
request and GET request URLs.
Internet Explorer 对最大请求路径长度也进行了限制,限制长度为2048字节。这个限制对 POST 请求和 GET 请求的URL均适用。
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.
如果您使用GET方法,您将受到最大2048字节的长度限制,减去实际路径中的字符数。
(注:实际可以使用的字符串长度=2048-请求页面路径字符长度)
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.
但是, POST 方法提交名称 / 值对不受 URL 长度的大小的限制。 因为这些名 / 值对是在请求中的header部分传输的,而不在URL中。
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length.
RFC 2616、 " 超文本传输协议 -- HTTP /1.1, " 未指定任何对 URL 长度要求。
由此文大家可以知道,实际在IE中可以使用的最大URL长度是2048字节减去您请求页面的路径长度。另外这个长度还受到服务端相应软件的限制。
--------------------
关于cookie,可以看一下:
Cookie常识
“同名Cookie”的分析
cookie,又见cookie
又到了一周回顾的时候了。本周确实没有做过多的事情。自己给自己加加压了
1、看了一下postgreSQL。准备用作mysql的补充。其实也考虑过用其它数据库做补充,比如mangoDB之类的。由于目前已经采用了redis。所以对于mongoDB的需求就不是那么明显了。
不过redis和mongoDB还是有区别的。但只有一台机器的话。redis分配了不少内存的情况下,再用mongo,内存就吃紧了
2、本周针对系统中原来的缓存功能做了清理,发现了一系列的问题,调整了一下。这确实是由于以前的功能单一而造成的原因
3、对于数据抓取,先作分词再做匹配。当匹配次数小于总次数的1/4时,认为原文是不匹配的。这个功能对于采用readability功能的抓取还是相对有点效果的
4、对于宽度固定的图片,原来在做PHP缩图的时候,保持宽高比的情况,现在做了调整,基于宽度进行调整(当然,这仅能用在宽度是指定的情况下。不是适合所有情况。当然对于图片过小的情况,也先作了放大处理。避免出现小图片)
5、nginx的php-fpm超时时间过短,导致上传大文件就会有问题,比如视频这一块的上传,就好纠结啊。尝试用cgi的方式上传,还没有折腾。
6、下周准备对于现有系统的API进行调整,业务增长的同事,原有架构需求也发生变化了。毕竟在最初写程序的时候不可能会考虑到所有会发生的情况,但事实上,这些业务正在逐步变化,没辙的情况下,只能做调整。否则,以后会更痛苦
在搜索共产党宣言的时候,突然发现搜索界面有变化了。

居然这样提示了。果然是做到了人性化了。
咦,这样也知道 ?

看了这篇文章后,对其中的一句话特别感兴趣,原文中有一条下划线,但那不是我有兴趣的。我的兴趣我加红。
我对老板说:“老板,我想做件疯狂的事情,我打算开家公司,在网上卖书。”之前我和他泛泛聊到过这个想法。“走,陪我散散步去。”他对我说。于是, 和他在纽约中央公园逛了两个小时后,他最后对我说:“你这个打算听起来是很靠谱,但这个事情更适合那些眼前没有一份好工作的人去做。” 他的话让我苦思良久。
为了能做好这种重大的决定,我努力寻找正确的思考框架。我也和妻子讨论过这个念头,她对此非常支持:“不论你做什么, 我都百分百支持你。”她嫁给了我这么一个有着稳定职业道路的稳重的家伙,而我现在想去做的事情是如此疯狂,但她却对此百分百支持——这个决定最后还是完全 在于我自己。最后,我找到了一个框架,它能助你轻松做出人生的重大决定,我把它称作“遗憾最小化框架”。
我 把自己想象成80岁的模样,并思考:“现在回望我的一生,我要把遗憾事件的数量降到最低。”我知道在我80岁时,我不会因这次尝试而后悔,我不会后悔参与 到互联网这个我认定是了不起的事情中来。我知道,哪怕我失败了,我也不会遗憾,而我可能会因为没有尝试而最终后悔不已。如果你能想象自己年满八旬,并思考 “老了的我会怎么想呢?”这个问题,你就可以因此而摆脱每日琐碎的困惑的干扰。你要知道,当时我从那家华尔街公司离职创业时恰逢年中,这样连年终分红都没 我的份了。就是这类短期的事情会干扰你的判断,只要你把眼光放得更长远些,你就可以做好生命中的重大决定,而不至于日后后悔了。
via bijansabet.com
http://www.36kr.com/category/digest
本周没有什么大事发生,只是对于自己来说有几件事情要记住。
1、编码,关于编码这件事,我在文章出现乱码怎么办?已经记录了
2、mongo,虽然很多人说,如果只有一台服务器就不要用mongo了,但是想来想去,我大字段内容过多,而且访问频繁,短时间内居然不能做缓存,这才是我纠结的,毕竟只要做了缓存,那就什么都好说了
3、redis的订阅。我用的是yiiredis的订阅。然后事情就开始纠结了。在yii的event中,我写了一个小函数,将内容再存到redis中,但死活存不进去。可能还是闭包的问题。没有仔细查,实在没时间啊。
不过本周会测试一下,不用yiiredis组件中自带的订阅,再看一下究竟如何
4、其它就真没大事了