月份：2012年4月

HTTP/1.1之连接（第八章）

HTTP/1.1之连接（第八章）

8.1 持久性连接

目的：

在以前，没有持久性连接的时候，为了获取每一个URL都要进行一次TCP连接，这显然加重了服务器的负担，容易引起互联网的堵塞，因为你要多次进行三次握手，尤其是页面里面有很多内联的图片、css样式表、js文件时候，简直让人崩溃。所以，持久连接有以下特点：

继续阅读“HTTP/1.1之连接（第八章）”

HTTP/1.1阅读之信息实体

7 信息主体

信息主体是由信息头和信息主体两部分组成的，除非被Status-code或是请求方法限制了，导致没有信息主体（为空）。我们在这章讨论的时候，发送和请求是辩证唯物的。当客户端请求服务器的时候，客户端是发送方，而服务器是接收方，但是服务器返回信息的时候，服务器是发送方，而客户端则是接收方。

       entity-header  = Allow                    ; Section 14.7
                      | Content-Encoding         ; Section 14.11
                      | Content-Language         ; Section 14.12
                      | Content-Length           ; Section 14.13
                      | Content-Location         ; Section 14.14
                      | Content-MD5              ; Section 14.15
                      | Content-Range            ; Section 14.16
                      | Content-Type             ; Section 14.17
                      | Expires                  ; Section 14.21
                      | Last-Modified            ; Section 14.29
                      | extension-header
       extension-header = message-header

以上实体部分，有些选项是可选的，有些则是必须的。其中的extension-header可以不用升级协议版本就可以扩展信息主体，但是你不能期望人家
接收方能够正确的识别，如果对方识别不了，这个扩展区将被忽略，但是代理转发的时候，你不能随意的忽略这个扩展区，这很好理解，因为你是代理
你又不知道人家接收方能不能识别这个扩展信息。
 entity-body    = *OCTET
如果实体存在的话，他的编码方式是在信息头域的Transfer-Encoding来决定的，这东西就是用来保证信息能够被正确的传输。
如果实体信息存在的话，他们会由头域的Content-Encoding和Content-Type来确定的，这些头域定义了两层顺序的编码模型，例如：
entity-body := Content-Encoding( Content-Type( data ) )，其中前者一般用于定义使用了什么压缩方式，而后者type表示请求的是什么类型
如果没有指定，他就会去猜，实在猜不到就application/octet-stream这样了 
实体信息的长度是编码前的长度，4.4节已经定义了，如果去确定信息的长度。

HTTP/1.1阅读之响应

与上一章对应，一个响应信息的包含部分如下：

 Response      =        Status-Line               ; Section 6.1
                       *(( general-header        ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header ) CRLF)  ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2
其中比较重要的是Status-line行，他由以下部分组成：
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

继续阅读“HTTP/1.1阅读之响应”

HTTP/1.1阅读之请求

5.1 请求消息的构成

在上一章，我们知道一个请求的消息应该由以下几部分组成：

 Request       = Request-Line              ; Section 5.1
                 *(( general-header        ; Section 4.5
                 | request-header         ; Section 5.3
                 | entity-header ) CRLF)  ; Section 7.1
                        CRLF
                 [ message-body ]          ; Section 4.3
他们是请求头（由请求行、一般头、请求头和信息头）+信息主体构成。我们来看看请求行（Request-Line），他是由下面几部分构成的：
Method sp URI sp HTTP-Version CRLF,我们来像教科书一样，看看各个部分都是干啥的

继续阅读“HTTP/1.1阅读之请求”

慎用preg_replace的/e修饰符

最近，wooyun上面爆了一个ThinkPHP的漏洞（最新版已经修复），以前也是我用过的第一个框架，昨晚花时间重现了一下，查阅了下程序的原理，原来这东西还得慎用。主要是由mixed preg_replace ( mixed pattern, mixed replacement, mixed subject [, int limit]) 这个函数引起的，在官方说明中，

/e 修 正符使 preg_replace() 将 replacement 参数当作 PHP 代码（在适当的逆向引用替换完之后）。提示：要确 保 replacement 构成一个合法的 PHP 代码字符串，否则 PHP 会在报告在包含 preg_replace() 的行中出现语法解析错 误。

继续阅读“慎用preg_replace的/e修饰符”

HTTP/1.1协议阅读-第一章

我将逐渐完成http/1.1协议的阅读，在此期间，为了加深记忆，会写成一个系列的文章，文中所述，以个人理解为主，以英文为准，尽量靠近原文档，原因是，下载了一个中文版的，读起来发现很别扭，感觉像是从Google翻译，直接翻译过来的，不知所云。

先强制性的翻译几章，熟悉之后，希望能够加快阅读速度，今天先进第一章。

继续阅读“HTTP/1.1协议阅读-第一章”