http://book.douban.com/annotation/21608651/ cgi的最大局限是它的“无状态性”。一个http服务器是不会记住两个请求组成——这些请求要么全是到同一服务器的,要么是到一些不同的服务器。每种情况下,服务器完成请求后,就挂起并忘记曾顺便访问过的用户。 能够记住一个呼叫者上次接通时做了什么的能力叫做“记住用户的状态”。http以及cgi都没有自动保留状态信息,在web事务中与状态信息最相近的东西是用户的浏览器高速缓冲区和cgi程序的智能。例如,如果一个用户在填写一个表单时漏填了一个必须的字段,cgi程序不能弹出一个警告框也不能拒绝接收输入。那么,这个程序唯一的选择是要么输出一条警告信息,告诉用户单击浏览器的back按钮,要么再次输出整个表单,填入提供的字段值并让用户重试,或者修改错误或者提供遗漏的信息。 有几种解决这个问题的办法,但都不是很令人满意。有一种想法是保留一个包含来自所有用户最新信息的文件,当一个新的请求传来时,在文件中找到这个用户并假定基于用户上一次所做事情的正确的程序状态。这种想法的问题是很难识别一个web用户,即一个用户可能在今天没有完成操作而第二天又因其他目的再次访问这个站点。这种方法大量的精力都花费到了保留状态的算法上了,而这只是为了节省有限的一点时间。所以,这种解决问题的方法效率很低,并且它们忽视了其他的问题:即首先要识别用户。 你不能依靠用户来提供他或她的标识。不仅那些想匿名的用户,而且即使那些想让你知道他们名字的用户都可能一次又一次地将名字拼写错。那么,用ip地址作为用户标识又如何呢?也不好。每个通过同一代理的用户都使用相同的ip地址。在某一时刻,是公司内哪个雇员在呼叫呢?你说不出来的。不仅如此,现在许多人在每一次拨号时都使ip地址动态分配。你当然不会因为这一次john joe和jane joe的ip地址相同,就给john joe访问jane joe的数据的特权。 标识映射唯一可靠的形式是由服务器提供的,它运用名字和口令模式。即使这样,用户还是不能忍受每次请求时都需输入名字和口令,所以,服务器缓存数据并用前面提到的算法判断缓冲区何时变得非法。 假定你们单位的ceo没有使用其名字或其他可猜得到的东西作为口令,并且也没有人洗劫他秘书的抽屉,也没看过他监视器上的黄色便笺,那么在服务器告诉你他是ceo时你就有理由肯定他就是ceo。那么接下来做什么呢?你的cgi程序仍必须通过一些环节来防止ceo在查你的数据库时重复回答相同的问题。你的cgi程序的每个响应都必须包含从那点开始程序向前或向后进行的所有信息。这很麻烦但却很有必要。 第二个继承到cgi程序中的主要局限性是与围绕发送文档的设计http规范的方式有关。http不倾向于长交换和长交互性。这意味着当你的cgi程序要做一些像生成一个服务器推送的图形时,它必须保持连接打开。它是通过把各种图像都真正当成同一图像的组成部分而实现这一点的。 可怜的用户例览器还坚持显示“连接活动”的信号,以为它正在检索单个的文档。从浏览器的观点来看,文档只是偶尔有点过长。但从脚本的观点来看,文档实际上是由几十个(也许是成百个)独立的图像组成的,每个图像都是按顺序通过管道传输的,并且它被做为一个巨大文件的部分被标记,而这个文件实际上并不存在。 也许当下一代http规范出现,并且例览器和服务器被更新以能利用保持有效的协议时,我们将会看到一些真正的革新。同时, cgi就会成为真正的cgi。尽管cgi偶尔不那么优雅,但它还是非常有用——并且很有意思。”
CGI的局限性
最新推荐文章于 2022-11-17 14:12:01 发布