当一个包含大数值 Content-Length 的 HTTP 请求被发送到内建的 PHP web 服务器后，可以触发拒绝服务问题（DoS）。

Bug 61461

Content-Length 头的值被直接传入了 premalloc() 函数，在 sapi/cli/php_cli_server.c 第1538行。然后 Zend/zend_alloc.h 的内联函数 malloc() 将报错，终止进程，抛出“Out of memory”错误。

static int php_cli_server_client_read_request_on_body(php_http_parser *parser, const char *at, size_t length)
{
php_cli_server_client *client = parser->data;
if (!client->request.content) {
client->request.content = pemalloc(parser->content_length, 1);
client->request.content_len = 0;
}
memmove(client->request.content + client->request.content_len, at, length);
client->request.content_len += length;
return 0;
}

把 Content-Length 设置为 2^31 – 10，也就是接近32位系统的上限值，能够重现这个问题。

测试脚本：
下面这个 HTTP 请求将触发这个bug。

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 2147483648

A=B

正确结果：
我们预期得到一个有意义的错误信息。

Invalid request (Requested Content-Length is larger the allowed limit of XYZ)

实际结果：
PHP 5.4.0 Development Server started at Tue Mar 20 19:41:45 2012
Listening on 127.0.0.1:80
Document root is /tmp
Press Ctrl-C to quit.
Out of memory

Qt开发工具包正在大修，它刚刚发布了Qt 5 Alpha，正式版预计将在今年晚些时候发布。

Qt 5将带来理念的变化，它的重心从传统的widget系统转变到Qt Quick——用于构建富界面的声明脚本框架。Qt Quick 在Qt 4.7中首次被引入进来，作为创建良好移动体验的基石。它在Qt 5中将扮演核心角色。Qt开发者将可以用QML（描述用户布局结构的声明语法）和JavaScript创建应用程序，C++ 将只用于实现扩展Qt Quick 运行时功能的插件库。

拍照分享应用Instagram刚刚被Facebook以10亿美元的现金和股票收购。但是你知道吗，Instagram创立仅551天，团队只有13个人，其中两位还是在上个月的SXSW期间加入。而背后的9位神秘投资人同样扮演着重要角色。下面我们来看看这20位幸运儿（两位刚刚加入的新员工未计入内）：

Instagram联合创始人兼CEO Kevin Systrom

创立Instagram之前，Kevin Systrom以前是 NextStop的产品经理，更早则是Google收购部门的一名员工。Systrom拥有Instagram 40%的份额。

Instagram另一位联合创始人Mike Kriege

在创立Instagram之前，Mike曾是Meebo的用户体验设计师和工程师，同时还是斯坦福大学的在读研究生。Kriege拥有Instagram 10%的份额。

Dan Toffey负责Instagram的社区运营

Dan Toffey于2012年3月加入Instagram，主要负责社区运营。加入Instagram之前，Toffey在一家期货交易机构担任网站沟通经理。

Josh Riedel于2010年加入，主要工作为社区运营以及伙伴关系维护，之前是NextStop的社区运营经理。

Philip McAllister是Instagram的工程师，在之前工作的创业公司被Facebook收购后于2012年3月加入Instagram。看来他仍然逃不出Facebook手掌，加入的第二家创业公司又被Facebook收购，不知这次他会否继续跳槽。

作为 AppThat的创始人和SimpleGeo的工程师，Ryan Gomba现在是Instagram的开发人员，于2012年3月加入。

Bailey Richardson也是今年3月份才加入Instagram，目前也主要负责社区运营，2009年从斯坦福大学毕业后在UGallery担任社区与市场营销经理。

Amy Cole负责Instagram的商务运作，于2011年10月份加入Instagram。之前负责著名化妆品连锁Sephora（丝芙兰）的商务拓展。

去年11月份加入Instagram的工程师Gregor Hochmuth也曾是Google的一位产品经理。

Instagram的社区布道师Jessica Zollman

于 去年8月加入Instagram的Zollman在自己的LinkedIn页面上说：“作为Instagram社区的布道师，我部分代表着 Instagram的用户。我会通过Instagram、Twitter、Tumblr以及Facebook介绍我们公司以及公司的产品。我提供实时客服 支持、沟通事宜以及向产品团队传达用户对产品的改进建议。我不仅负责Instagram的线上活动，也负责线下活动。”加入Instagram之 前，Zollman曾在一家实验室担任客户关系专员。

Shayne Sweeney自称是一位创业黑客，2010年10月份之前曾是Credentify的创始人和Build.com的首席工程师。

下面我们看看Instagram的9位投资人：

Quora联合创始人Adam D’Angelo是Instagram的天使投资人

作为前Facebook的CTO，Adam D’Angelo与Charlie Cheever联合创立了Quora，2011年2月他对Instagram的A轮投入700万美元。

Twitter和Square联合创始人Jack Dorsey是Instagram另一位天使投资人

Jack Dorsey在创立Twitter后，又创立了移动支付Square，2011年2月Instagram的A轮融资中，Jack Dorsey对其投入了700万美元。

Google早期员工Chris Sacca也于2011年2月对Instagram的A轮融资投入700万美元，他同时是Twitter的天使投资人。

Baseline Ventures是Instagram的种子和A轮投资机构

2010年3月Baseline Ventures 向Instagram提供了50万美元的种子投资，2011年2月的A轮融资中又投入700万美元。该投资机构由Steve Anderson创立。

 Andreessen Horowitz 也是Instagram的种子投资人，但是当它成为其投资的另一家公司PicPlz的竞争对手后放弃了继续投资，目前仍然拥有Instagram的 10%。Andreessen Horowitz于2010年3月向Instagram投资50万美元种子基金。

Instagram上周从红杉资本、Thrive以及Greylock融资5000万美元，Benchmark Capital也对其进行了投资，估值为5亿美元。

正如我们所分析的 那样，2年时间Instagram从0到10亿美元的崛起有其偶然性，它在正确的时间、正确的地点做了一件初看起来不一定正确的事情。但是通过对 Instagram的团队成员进行解析，我们又更多的看到了其成功的必然性。因此我们可以说其成功是偶然与必然的叠加，而在这个过程中，投资人同样扮演着 不可或缺的角色。也许正是美国这种成熟的创投环境成就了它，但是成功依然没有捷径。

这是来自新加坡的 iOS 开发者 Kent Nguyen 发表在1月底的一篇博文。这篇吐槽文在 iOS 开发圈子里流传甚广，从原文150多个评论就可见一斑，现翻译如下。让我们开门见山吧：做一个iPhone应用需要花多少钱？ 就是这个最常见的问题，我的很多朋友（大多是些西装革履的商务人士），还有我那些个对技术一知半解的客户们，他们都问过我这个的问题。通常，我会先给出一 个大致的报价，这个报价并没有细致到需要签合同确认每一个功能点的地步。即便是这样，每当的我报价一出口，对方都毫无例外的给惊着了（当然不是因为便宜）。

说实话，我没有狮子大开口。看看StackOverflow上这个著名的帖子吧，讨论的是开发Twitterific这 样一款应用需要多少钱，后来讨论范围扩展到开发一个iOS应用的合理费用范围。虽然这个帖子是在2008年发布的，而帖子的最佳答案是由一名来自 Twitteriffic的开发人员于2010年回答的，但是时至今日，帖子里面讨论的数字仍然是很靠谱的，而且我预计到2012年底依然有效。而我的报 价和这个帖子里面的数字比起来，简直是小巫见大巫了。

现在的趋势是，什么公司什么业务都想搞个iOS客户端，并且这种趋势在2012年看似依然火爆。所以我想起来写这篇博文，我想说一下开发一个iOS应用会 碰到的各种细节问题和横生的变数，借此解释为什么iOS应用开发成本这么贵。如果你在考虑搞一个iOS应用，而你本身是搞业务而不是做技术的，如果你目前 正在招标或者仅仅是想了解一下，那我这篇博会对你有帮助。当然，我说的东西并不局限于iOS应用开发，对Android、Windows Phone或者是Blackberry（如果RIM还能活的话）等移动应用平台基本上也是适用的。

开发之前需要仔细考虑的

别做拍脑瓜的决策，在开工之前你需要考虑的比你想象的要多。我通常会帮助或者指导客户把以下几个要素都过一遍：

一：和客户谈他们的移动应用，最让我吃惊的是他们从来没有想过支撑一个iPhone应用运行，背后需要涉及到的方方面面。他们想象中的iPhone是独立 存在于这个宇宙的，是如此的简单，以至于他们要我很快就给出一个项目预算报价，而不用讨论诸多细节。我问他们：“你们是否考虑过后台服务器的事情？你们的 应用需要和后端服务器做数据通讯？” 什么，听不懂？好吧，我用地球人的语言再把这个问题讲 一遍：“你们的应用不是需要用户注册嘛，你们考虑过把用户的数据存放在哪里了吗？我们需要一个地方去保存这些以后会用到的数据。” 第一次碰到这样的客户时，哥简直就怒了。后来我发现这不是客户的错：我是搞编程的，CS架构对我来说就像吃饭睡觉一样是不假思索的东西，而我的客户尽是些 高富帅，他们懂个毛CS架构！

所以，如果你不大懂技术，那请仔细听我说：如果你想做的移动应用需要用户注册和登录，或者你想随时控制移动应用的一些输出，甚至是你仅仅是需要一个用户反馈意见调查表这么简单的功能，那么，你得搞一台后端服务器。

二：好了，现在你知道你需要一台后端服务器。同时你还需要想办法让你的iOS应用和你的服务器能够对话，就是相互间接收数据什么的。不，这个问题不是简答 靠什么标准的即插即用的东东就能解决的，不是你们想象的那样！所有的东西都需要定制化开发，这就好比发明一门语言：你希望你的服务器和你的应用之间能够通 过一种语言沟通，但是你不希望其他人听得懂这门语言。

用行话说这就是制定服务器端API接口，或简称API。这些API应该在开发iPhone客户端之前就到位了。为什么？因为你必须先规定好一门语言的单词和语法，然后才能用这门语言说话吧！？好了，这就带出了第三点—如何开发这些API。

三：API的成功定制是项目成功的一半（反之亦然），所以千万不要掉以轻心。你要考虑你的业务数据模型、业务流程、调用业务需要提供的参数、特定事件发生 时数据间该如何互动等等。简单来说，我们要做的就是开发一个网站，上门跑着你的业务流程，只不过这个网站的所有运行结果都不是通过网页形式展现出来，而是 呈现在一行行的文本和数字中。举个例子：一个登录成功的反馈页面仅仅包含YES一个单词。

iPhone应用需要访问这些预先定义好的接口，并且按预定义格式提供必要的输入（比如用户名和密码），然后要对服务器端的反馈（YES或者NO）做出解析处理。所以，没有什么移动应用能够自动的含有用户注册和登录功能。

服务器端开发需要考虑的问题太多了：选择服务器，选择用什么语言开发，主机放在哪里才能增加访问速度，等等，这里我就不展开了。如果这一切对你来说很陌生，那么你最好去问问团队里的技术负责人，或者干脆让开发人员做决策。

四: 所以，关于服务器端API，你或者让自己的技术团队把它开发好，再将完善的API文档交给iPhone应用开发人员；或者你支付iPhone应用开发人员 额外的报酬来搞定这些。你找的iPhone应用开发人员可能会服务器端开发也可能不会。如果他会的话，我建议最好让他也同时负责服务器端开发，因为他最清 楚iPhone应用中需要哪些服务器端API。

如果你的服务器端API已经存在了，那么除了向iPhone应用开发人员提供相关文档之外，你还要考虑让他能够便捷的同服务器开发团队沟通，因为大多数情况下，iPhone应用需要在已有API基础上增加一些新的接口。
 
现在我们来看看iPhone应用开发本身

扯了大半天，我们终于开始谈iPhone应用开发本身了。一般来说，iOS平台上做所有事情都不能随心所欲。你最好在开发人员写代码之前把所有的需求都确认好好。这和开发网站不一样，按照实现签订的合同开发iOS应用，开发过程中对需求变更的容纳度可能很低：

用户界面： 无论你打算采用iOS标准界面还是自定义元素，在开发开始前一定要确认清楚，因为应用的程序架构是根据界面和用户使用流程来设计的。一个很好的例子就是在 界面底部使用了iOS标准的标签栏（Tab Bar），此后如果你想让标签栏里面的图标变成彩色的，这个代码改动量可没你想象的那么小！

代码之间的耦合： 如果是开发网站，你可以随意的添加一个页面或者一处链接。做iOS应用就没有那么简单了，很多东西一开始都要设计好，后期的一处改动会牵连很多东西，具体 原因是你无法理解的。iOS应用的代码写好之后，再改动行不行？行！但必须小心。 这就像设计电路板一样， 如果你不小心把那根线搭错了，整块电路板就会不工作。有人说架构优良的程序可以有很高的延展性，那纯属纸上谈兵。在About屏幕上添加一个电子邮件按钮 可能只需要几行代码的工作量，而添加一个转发到新浪微薄的按钮（译者注：原文是添加一个Facebook Like）就完全不是那么简单的事儿了！

让一个iPhone应用同时也支持iPad： 如果要评选最坑爹“需求变更”，那么这个绝对是当之无愧的。理由很简单：支持iPad根本不是TMD什么附加功能！iPad应用基本上都比iPhone应 用来得要复杂，界面设计和用户体验也大不一样。我问你，制造一辆电动自行车，然后把它改装成一部烧汽油的摩托车，这能是一回事儿吗！？电动自行车跟摩托车 看起来是很像，但是制造它们完全是两码事。

拿广受欢迎的Facebook官方应用来说，它的iPhone和iPad版本看似相似，实际用户操作流程完全不同。不仅仅是界面上的不同会带来额外的工作，对后台服务器API的需求也可能不一样。拿我熟悉的一个应用Denso来说（我熟悉它因为这是我开发的），它的iPad版本比iPhone多了几个功能，这些都需要额外的服务器端API来支持。记住，iPhone和iPad应用的用户体验需求是完全不一样的。

准备好开始了吗？
希望此文能够帮助你和你的团队了解移动应用开发幕后的方方面面。除非你们要做一个像计算器那么简单的单机应用，否则你们很难用极低的成本搞定。综上所述，如果你觉得外包成本太高，那你只好招人自己开发。
当然，如果你决定了要外包移动应用开发，那么我还要提醒一点：公司政治。 如果你是在一家大公司或者有着严格制度的机构里面干活，那么帮助合同开发者搞定那些个规章制度上的繁文缛节，对你来说是非常重要的一项工作，必要的时候甚 至可以做一些政策上的变通。 我同几个大型企业客户接触过，当我要求看他们的服务器端数据接口的时候，他们流露出很不安的表情。我想这或许是因为他们受制于公司规定而不能透露信息，这 无可厚非；或者他们还没有想好这种情况下该如何操作；或者他们的品牌制度蛋疼到需要在移动应用的每个屏幕上都摆着公司logo！最终我没有和这样的企业客 户合作，因为我无法想象如果有一天我需要增加一些服务器端API接口的话，和他们的规章和流程折腾，那将会是多么悲剧的事情。
PS：开发移动应用很耗费时间，你最好有耐心。
 
英文原文：Kent Nguyen   编译：伯乐在线 – 陈远

提示：随着RESTful Web services的流行程度不断地上升，开发人员需要知道如何避免开发中的陷阱以及让开发出来的Web service达到自己能做到的最好程度。

过去的几年里，我们看到RESTful Web services变得流行起来是有好些原因的。这里有十个技巧你应该要做的，它们能让你的RESTful Web Service更加高水准并且被其他开发人员使用起来更加简易。

1. 不要寻找一个官方的“REST 标准”

REST是一个概念，不是一个标准。因此没有任何的要求让你的 RESTful Web service在一个特定的方式下运行。话虽如此，但……

2. 还是坚持一些标准

……你的 RESTful Web services 应该遵循至少一些标准！例如用户认证的OAuth协议、数据交换的JSON和XML、网络传输和自控制的HTTP协议还有URI标准。如果你想要一个更加完整的包，开放数据协议OData是一个有效的选择（因为它够大？）。因为没有人说“REST必须坚持这些标准”这样的话，并不意味着你就应该按照自己的意愿来。

3. 确保你的文档是完美无瑕疵的

使用 SOAP 协议的WSDL（Web Service 定义语言）系统，如果你有一个基于WSDL、可以自动生成代码的工具，那么开发Web Service是相当简单的。但如果用 REST ，由于services不需要严格的定义，并且它们运行在被称为适当地正确工作的理念上。这意味着service的文档必须要非常严谨。如果你要开发一个Web Service一定要确保你的文档百分百的正确。

4. 提供 JSON 输出

JSON 已经迅速的变成web上的重要标准。首先,它很方便,因为它可以很容易地让JavaScript以最少的编码量来使用Web Service。现在有很多库可以让服务端与客户端的JSON交互工作的非常好。

5. 不要漏掉 XML

说到输出，XML 依然像往常一样非常重要。为什么要同时支持 XML 和 JSON 呢？因为并不是所有的系统都能使用 JSON 的，但如果一个系统能被称为 Web Service ，那么它就一定会被规定去处理XML。现在有成堆的遗留系统，举个例子，它是用XML工作而不是JSON。并且不是所有开发人员都想去mixing和匹配JSON跟XML的。因此要确保你的Web service系统支持这两种格式。通过HTTP请求头的“Accepts”参数来做这种支持而不是通过不同的包含参数的 service URL 来做。

6. 理解 HTTP 动词

REST Web services 其中一个很核心关键的是HTTP协议已经定义好的一大块功能。而这其中最基本的一部分就是 HTTP 动词，例如 GET、POST 。而这些基本功能在REST中已经被很好地、充分地理解，一些想法仍然不断地涌现，例如使用打补丁的方式更新实体中一些特定属性而不是整个实体。

7. 理解 URI 路由的重要性

RESTful Web services 在很大程度上是通过URI来决定干什么的。举个例子，在一次 GET 请求中，典型的URI路径会包含一个实体的主键值（或者其他标识键值）来检索获取实体的数据。例如 “http://www.example.com/service/entityname/76″ 将检索名字为 entityname， 主键值为 76 的实体。使用 REST Web services，URI 不仅是一种访问service的方式，还是控制service和作为传达你的需求的信号载体。

8. 在版本管理下进行更新维护

一件很诱人的事是你只需对唯一一个版本的service做更新维护。但真的不要这样做！确保你每一次发布更新后都新开一个分支版本来维护。最简单、最常见的办法是让你的service URI 带上版本号，通常是路径的一部分。人们最需要的一件事就是使用更新后的软件没有任何新的问题或警告出现。

9. 与你的用户保持联系

因为用户不会主动发现你的更新，因此你和你的用户保持联系就显得十分重要了。例如，当你为你的service发布一个新的版本时，你应该给每一个用户发一封邮件让他们知道，以及提供旧版本的缺陷信息。

10. 提供示例代码

对你的用户来说你要做的最好的一件事之一就是给他们提供示例代码。确保你给出的代码至少包含以下几个主要的开发语言：Java、.NET、JavaScript、Ruby还有Python。如果有必要的话，雇佣一个顾问将这些代码放在一起。因为它对于你的 service 能否被采用是绝对重要的。还要确保你的许可协议可以让你的用户没有任何风险影响地使用你的示例代码，例如可以使用 MIT 或 BSD 许可协议。

一些跟 RESTful 相关的开源软件请看这里。

英文原文，OSChina原创翻译