Chinaunix

标题: 您了解HTTP么？工作中奇葩HTTP问题经验大征集！（获奖名单已公布-2014-7-9） [打印本页]
作者: send_linux    时间: 2014-06-05 15:58
标题: 您了解HTTP么？工作中奇葩HTTP问题经验大征集！（获奖名单已公布-2014-7-9）
获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-4145264-1-1.html

活动背景：
你了解 HTTP 吗？
你认为你真的很了解 HTTP 吗？
你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
你知道各种 HTTP 返回码的实际意义吗？
你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
你又了解 SPDY 吗？
《图解 HTTP》这本书会把上述问题剖析得淋漓尽致，尤其对于互联网运维的小伙伴们，真的是一本值得学习和参考的佳作！

本期话题：
说说你在学习、工作中遇到的 HTTP 的那些奇葩事（阐述清楚问题，并说明是如何解决的）

活动时间：
2014年6月5日-6月25日

本期嘉宾：
ChinaUnix资深版主：platinum

活动奖品：
从中抽取5名用户，获得《图解HTTP》一本，更多图灵新书，点击这里

作者： (日)上野 宣   
译者： 于均良
丛书名： 图灵程序设计丛书
出版社：人民邮电出版社
ISBN：9787115351531
上架时间：2014-4-10
出版日期：2014 年5月
开本：32开
页码：250

活动要求：
1、 要言之有物，不能低于20个字。
2、 本次话题主要关注http及运维相关的技术讨论，其他问题可能不做重点
作者: yunas    时间: 2014-06-05 16:02
沙发我的。HHTP真的叠成出一本书。
作者: seesea2517    时间: 2014-06-05 17:23
这方面接触不多，返回码之前有看到一个挺有趣的科普故事，不过也没什么印象了。
作者: 东北胖子    时间: 2014-06-05 17:29
还真不了解。
作者: jbqncn    时间: 2014-06-05 17:31
本帖最后由 jbqncn 于 2014-06-13 10:05 编辑

你了解 HTTP 吗？
有点了解
你认为你真的很了解 HTTP 吗？
不太深入
你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
主要区别有三个这个是当年毕业设计做简单HTTP服务器学到的。
一个是支持虚拟主机(主要是依靠Host头)。
一个是支持keepalive就是在一个TCP连接里可以发多个HTTP请求，这样就要求每个HTTP请求都要有content-length来定界。
还有一个记不太清了。。
你知道各种 HTTP 返回码的实际意义吗？
1xx 代表消息类型
2xx 代表成功
3xx 代表重定向
4xx 代表客户端发来的请求有误
5xx 代表服务器内部错误
你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
有些HTTP头即可以出现在Request里，也可以出现在Response里，比如content-length
有些HTTP则只出现在一类消息中比如 server ？
HTTP1.1里头太多了，等要用到了再研究吧。
你又了解 SPDY 吗？
SPDY是HTTP2.0是哪几个字母的缩写或者主要有什么改进都不太清楚，主要是现在也没大规模应用，所以也没了解太深，不过貌似很多HTTP服务器有支持。
以上回答全部错误，就连SPDY不是缩写也被明显指出。http://zh.wikipedia.org/wiki/SPDY


作者: jimmy-_-lixw    时间: 2014-06-05 17:52
了解点，占位支持好话题。
作者: lkk_super    时间: 2014-06-05 18:14
遇到過 HTTP 報文被改寫了
原來的 Content－Length 被改成了 0

解決麼？ 無解
作者: chenzhiquan2000    时间: 2014-06-05 19:41
提示: 作者被禁止或删除 内容自动屏蔽
作者: 陌路巨额投入    时间: 2014-06-05 20:53
回复 1# send_linux


    前段时间想通过HTTP来上传文件，发生了一件奇葩事，，哈哈。。不多说直接上代码：
void COSBHTTPClient::UploadFile( TOSBDownloadParam& aParam, TDesC8& aContentType )

//aContentType  = “multipart/form-data; boundary=AaB03x”

{

        iClient->CancelTransaction();

        

        RFile rFile;

        RFs fs;

        if( KErrNone != fs.Connect() )

        {

                return;

        }



        //Open file where the stream text is

        TInt error = rFile.Open( fs, iDownloadParam->iFileName, EFileShareAny );//EFileRead );

        CleanupClosePushL( rFile );

        TInt size = -1;

        User::LeaveIfError( rFile.Size( size ) );        

        HBufC8* aXmlBuffer = HBufC8::NewLC( size );

        TPtr8 bufPtr( aXmlBuffer->Des() );

        error = rFile.Read( bufPtr );

        CleanupStack:op( aXmlBuffer ); // aXmlBuffer

        CleanupStack:opAndDestroy( &rFile ); // rFile

        fs.Close();

        _LIT8(KDataStart,"--AaB03x";

        _LIT8(KCrlf,"\r\n";

        _LIT8(KContent,"Content-Disposition: form-data; name='userfile'; filename='";

        _LIT8(KFileCompletion,"'";

         

        _LIT8(KContent2,"Content-Type: text/plain";

        _LIT8(KContent3,"Content-Transfer-Encoding: binary";

        _LIT8(KDataEnd,"--AaB03x--";

         

        HBufC8* iPostData = HBufC8::NewL( 650+ size );

         

        TPtr8 iPostDataPtr = iPostData->Des();

        iPostDataPtr.Zero();

         

        iPostDataPtr.Append(KCrlf);

        iPostDataPtr.Append(KDataStart);

        iPostDataPtr.Append(KCrlf);

        iPostDataPtr.Append(KContent);

//        iPostDataPtr.Append(aFname);

        iPostDataPtr.Append(KFileCompletion);

        iPostDataPtr.Append(KCrlf);

        iPostDataPtr.Append(KContent2);

        iPostDataPtr.Append(KCrlf);

        iPostDataPtr.Append(KContent3);

        iPostDataPtr.Append(KCrlf);

        iPostDataPtr.Append(KCrlf);

        iPostDataPtr.Append(bufPtr); //the file in binary

        iPostDataPtr.Append(KCrlf);

        iPostDataPtr.Append(KDataEnd);

        iPostDataPtr.Append(KCrlf);

        iClient->IssueHTTPPostL(URL, aContentType, iPostDataPtr);

        iObserver.ClientEvent( MOSBHTTPClientObserver::EEventConnecting );

}
复制代码void CClientEngine::IssueHTTPPostL( const TDesC8& aUri,

                const TDesC8& aContentType, const TDesC8& aBody )

{

        SetupConnectionL();



        // Parse string to URI

        TUriParser8 uri;

        TInt ret = uri.Parse( aUri );

        // Copy data to be posted into member variable; iPostData is used later in

        // methods inherited from MHTTPDataSupplier.

        delete iPostData;

        iPostData = aBody.AllocL();

        // Get request method string for HTTP POST

        RStringF method = iSession.StringPool().StringF(HTTP::EPOST, RHTTPSession::GetTable());



        // Open transaction with previous method and parsed uri. This class will

        // receive transaction events in MHFRunL and MHFRunError.

        iTransaction = iSession.OpenTransactionL( uri, *this, method );

        // Set headers for request; user agent, accepted content type and body's

        // content type.

        RHTTPHeaders hdr = iTransaction.Request().GetHeaderCollection();

        SetHeaderL( hdr, HTTP::EUserAgent, KUserAgent );

        SetHeaderL( hdr, HTTP::EAccept, KAccept );

        SetHeaderL( hdr, HTTP::EContentType, aContentType );

        // Set this class as an data supplier. Inherited MHTTPDataSupplier methods

        // are called when framework needs to send body data.

        MHTTPDataSupplier* dataSupplier = this;

        iTransaction.Request().SetBody( *dataSupplier );

        // Submit the transaction. After this the framework will give transaction

        // events via MHFRunL and MHFRunError.

        iTransaction.SubmitL();

}
复制代码void CClientEngine::MHFRunL( RHTTPTransaction aTransaction,

                const THTTPEvent& aEvent )

{



}
复制代码现在与服务器的连接可以成功，但是body总是传不上去，从log看MHFRunL的aEvent，走了下面3种状态
THTTPEvent::EGotResponseHeaders
THTTPEvent::EResponseComplete
THTTPEvent::ESucceeded
可是THTTPEvent::EGotResponseBodyData始终没有走到，自己总是以为上传失败，苦苦纠结了一个下午，，，最后才发现我是POST，不走THTTPEvent::EGotResponseBodyData，除非在POST给服务器的时候服务器还有返回信息才会走。。。。
作者: forgaoqiang    时间: 2014-06-06 00:20
本帖最后由 forgaoqiang 于 2014-06-23 14:41 编辑

HTTP 还是比较了解滴 好不容易看完了《HTTP权威指南》 ~~ 哈哈 过两天从现场回去了再来讨论~

1、你了解 HTTP 吗？
对于HTTP还是比较了解的，工作中需要配置Apache和Nginx服务器，很多时候就是和HTTP在打交道，同时需要写一些Web的程序，对HTTP的各种状态操作会大大影响网络性能的。现在主要做无线这一块，AC控制器直接使用HTTPS（和HTTP相同哦）进行通讯，很多Heartbeat通讯的时候直接使用Header方式即可，没有必要使用开销很大的GET/POST方式。

2、你认为你真的很了解 HTTP 吗？
⊙﹏⊙b汗 让这个问题一问，突然没有自信了。我真的还是比较了解HTTP的，至少把《HTTP The Definitive Guide》看了个差不多，大部分内容都理解了，应该是很了解了。虽然实际生产应用中大部分的HTTP协议功能并没有使用。

3、你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
这个比较实用的两个区别还是晓得的，如下所述：
①其实最大的最有意义的区别就是 长连接的改进（Keep-alive），能够在一个HTTP连接里面传输多个文件，而不像是HTTP1.0里面每次请求都得来一遍：TCP三次握手+HTTP过程，大大的提高性能。
②“偏移”字节功能，能够支持不从0开始传输，因此能够支持所谓的断点续传，对于移动网络还是比较实用的功能，因为移动网络经常会出现不稳定的问题，只要服务器端记录了已经发送的字节数就能实现断点续传，而不用重新发送。
其实具体的区别只要查看 官方的定义文档RFC即可知道，
  1. RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0
  2. http://www.w3.org/Protocols/rfc1945/rfc1945
  3. RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
  4. http://www.w3.org/Protocols/rfc2616/rfc2616
复制代码
4、你知道各种 HTTP 返回码的实际意义吗？
是的，大部分的返回码还是知道的，因为使用Ajax技术就有必要知道返回码的含义，以便于根据对应的状态码进行相应地回调操作。

我只说下ajax编程中的5个状态吧，其实和HTTP的状态位是对应的，其他的返回码直接查询下列表即可。
  1. 0 - (未初始化)还没有调用send()方法
  2. 1 - (载入)已调用send()方法，正在发送请求
  3. 2 - (载入完成)send()方法执行完成
  4. 3 - (交互)正在解析响应内容
  5. 4 - (完成)响应内容解析完成，可以在客户端调用
复制代码
5、你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
是的，对于一部分常用的还是很清楚的，Request请求的内容不多，主要是带上一些客户端信息以及请求的主机、方法、能接受的编码等等信息。
Response Header中包含的内容比较多，包括Content-length（用来定界）、返回的文件类型，对于网络性能比较相关的就是缓存相关的字段，比如过期时间、是否允许缓存等。

6、你有了解 SPDY 吗？
这个倒是听说过，应该是Chrome的专有技术，通过对HTTP的进行压缩（增加有效负载，和TCP/UDP那种类似），优化后的HTTP能够减少协议流量自身开销，把更多的空间留给有效的负载（高层数据），SPDY不是一堆单词的缩写，只是Speedy的缩写而已。

现在发现HTTPS长连接能够当做socket来使用，C/S结构采用高层协议HTTP来作为通讯协议，开发效率高、难度低，即使Ubnt这样的厂家的控制器都有基于HTTPS进行传输的，果然HTTP还是非常方便的，奇葩的事情有一个：
当时给建设银行的热点系统做联通短信对接，不知道为什么短信通道那边总是返回 200（代表成功）的状态码，但是content-length总是0，最后才发现是Nginx设置了时间内限制，每分钟只允许20次请求，然后就进行虚假响应，差点被坑死，使用自己的短信网关近万条才发现这个问题。

作者: zealoussnow    时间: 2014-06-06 10:44
前段时间跟同事一起做一个项目，其中上层要调用底层的python脚本，人家问我传参是用get方式还是post方式，一下子把我问晕了，毕竟第一次接触这个，然后我问了一个很傻的问题，有区别么，对方以呵呵了事。后来用python写一个分片下载的一个玩意后，才开始对http的一些东西有了解。
作者: folklore    时间: 2014-06-06 14:48
了解，
看rfc看的～～

完毕
作者: lthao2010    时间: 2014-06-06 16:53
forgaoqiang 发表于 2014-06-06 00:20
HTTP 还是比较了解滴 好不容易看完了《HTTP权威指南》 ~~ 哈哈 过两天从现场回去了再来讨论~


具体那本书啊 能提供一个吗？
作者: expert1    时间: 2014-06-06 16:54
http协议真是杂乱啊，要看RFC会死人的。

http1.0/1.1区别之一就是keepalive还有7788的header.

做cdn的缓存经常用到这个
作者: expert1    时间: 2014-06-06 17:59
此外http header里host域，1.0是没有的，包括cache/gzip等。
作者: platinum    时间: 2014-06-06 18:40
expert1 发表于 2014-06-06 17:59
此外http header里host域，1.0是没有的，包括cache/gzip等。

可以详细说说，其实还有很多差异
作者: ls2015    时间: 2014-06-06 22:15
<HTTP权威指南>看了一半，了解一些关于HTTP的知识。个人感觉如果不做浏览器的话，了解基本的HTTP知识就够用了。
作者: forgaoqiang    时间: 2014-06-06 22:24
额 就是 《http the definitive guide》

回复 13# lthao2010


   
作者: 芬达7402    时间: 2014-06-07 05:33
遇到坑爹的问题：我们的健康检查是用HEAD方法请求页面的，结果该死的用户屏蔽了HEAD方法，导致健康检查失败，一天到晚报警。
作者: 陌路巨额投入    时间: 2014-06-08 15:24
好活动  支持支持。。。
作者: j591378033    时间: 2014-06-09 12:31
之前做web服务器有简单了解过http协议，对于状态码也就熟悉几个常见的！
作者: action08    时间: 2014-06-10 08:02
回复 9# 陌路巨额投入


            User::LeaveIfError( rFile.Size( size ) );        
你确定这行代码用对了吗？？
作者: 陌路巨额投入    时间: 2014-06-10 08:43
回复 22# action08


    没错啊 我调试仿真过哦
作者: huobing1115    时间: 2014-06-10 09:14
http理解不深，学习:wink:
作者: 流氓无产者    时间: 2014-06-10 09:24
很不错了，http是影响大家思维的几种协议之一
作者: zylthinking    时间: 2014-06-10 16:29
陌路巨额投入 发表于 2014-06-05 20:53
回复 1# send_linux


这年头 symbian 还活着啊
作者: platinum    时间: 2014-06-10 17:49
谁说说对于 HTTP/1.0 和 HTTP/1.1 来说，请求头里没有 Connection: keep-alive 的话，服务器会如何处理？
作者: send_linux    时间: 2014-06-10 18:02
platinum 发表于 2014-06-10 17:49
谁说说对于 HTTP/1.0 和 HTTP/1.1 来说，请求头里没有 Connection: keep-alive 的话，服务器会如何处理？


嘉宾终于出现了。。。。
作者: kinfinger    时间: 2014-06-10 18:57
纯粹是顶楼主
作者: 陌路巨额投入    时间: 2014-06-12 09:54
支持支持
作者: platinum    时间: 2014-06-12 16:03
流氓无产者 发表于 2014-06-10 09:24
很不错了，http是影响大家思维的几种协议之一

可以详细说说
作者: hexilanlan    时间: 2014-06-13 11:23
不了解。。。。
向往之
作者: hxksd    时间: 2014-06-13 14:33
常用的请求方式是GET和POST.

l         GET方式：是以实体的方式得到由请求URI所指定资源的信息，如果请求URI只是一个数据产生过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。

l         POST方式：用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，Post被设计成用统一的方法实现下列功能：

1：对现有资源的解释；

2：向电子公告栏、新闻组、邮件列表或类似讨论组发信息；

3：提交数据块；

4：通过附加操作来扩展数据库 。

从上面描述可以看出，Get是向服务器发索取数据的一种请求；而Post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中
作者: chenzhiquan2000    时间: 2014-06-13 20:31
提示: 作者被禁止或删除 内容自动屏蔽
作者: Swayer_Chen    时间: 2014-06-13 22:22
回复 27# platinum


    1.1 默认作为长连接处理

1.0 默认作为短连接处理


貌似是这样的吧，好久没有搞过http了~~~
作者: renxiao2003    时间: 2014-06-13 22:24
本帖最后由 renxiao2003 于 2014-06-13 22:26 编辑

你了解 HTTP 吗？
答：自认为还比较了解HTTP啊。
你认为你真的很了解 HTTP 吗？
答：基本上很了解了。HTTP常用的方法有Post，Get，Delete等。
你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
答：1.0和1.1的区别主要有8点：1、可扩展性，2、缓存，3、带宽优化，4、长连接，5、消息传递，6、Host头域，7、错误提示和8、内容协商
你知道各种 HTTP 返回码的实际意义吗？
答：返回码分5大类：
1×× 　　保留   
2×× 　　表示请求成功地接收   
3×× 　　为完成请求客户需进一步细化请求   
4×× 　　客户错误   
5×× 　　服务器错误   
纤细的说就是：
100 Continue
101 Switching Protocols
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 Unused
307 Temporary Redirect
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Menthod Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Reqeust Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Request Range Not Satisfialbe
417 Expectation Failed
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 Http Version Not Supported
你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
答：HTTP Request的Header信息
1、HTTP请求方式
GET 向Web服务器请求一个文件
POST 向Web服务器发送数据让Web服务器进行处理
PUT 向Web服务器发送数据并存储在Web服务器内部
HEAD 检查一个对象是否存在
DELETE 从Web服务器上删除一个文件
CONNECT 对通道提供支持
TRACE 跟踪到服务器的路径
OPTIONS 查询Web服务器的性能
说明：
主要使用到“GET”和“POST”。
实例：
POST /test/tupian/cm HTTP/1.1
分成三部分：
（1）POST：HTTP请求方式
（2）/test/tupian/cm：请求Web服务器的目录地址（或者指令）
（3）HTTP/1.1: URI（Uniform Resource Identifier，统一资源标识符）及其版本
备注：
         在Ajax中，对应method属性设置。
2、Host
说明：
请求的web服务器域名地址
实例：
例如web请求URL：http://zjm-forum-test10.zjm.baidu.com:8088/test/tupian/cm
Host就为zjm-forum-test10.zjm.baidu.com:8088
3、User-Agent
说明：
HTTP客户端运行的浏览器类型的详细信息。通过该头部信息，web服务器可以判断到当前HTTP请求的客户端浏览器类别。
实例：
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
4、Accept
说明：
指定客户端能够接收的内容类型，内容类型中的先后次序表示客户端接收的先后次序。
实例：
         例如：
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
备注：
在Prototyp（1.5）的Ajax代码封装中，将Accept默认设置为“text/javascript, text/html, application/xml, text/xml, */*”。这是因为Ajax默认获取服务器返回的Json数据模式。
在Ajax代码中，可以使用XMLHttpRequest 对象中setRequestHeader函数方法来动态设置这些Header信息。
5、Accept-Language
说明：
    指定HTTP客户端浏览器用来展示返回信息所优先选择的语言。
实例：
Accept-Language: zh-cn,zh;q=0.5
         这里默认为中文。
6、Accept-Encoding
说明：
         指定客户端浏览器可以支持的web服务器返回内容压缩编码类型。表示允许服务器在将输出内容发送到客户端以前进行压缩，以节约带宽。而这里设置的就是客户端浏览器所能够支持的返回压缩格式。
实例：
         Accept-Encoding: gzip,deflate
备注：
其实在百度很多产品线中，apache在给客户端返回页面数据之前，将数据以gzip格式进行压缩。
另外有关deflate压缩介绍：
http://man.chinaunix.net/newsoft ... od/mod_deflate.html
7、Accept-Charset
说明：
         浏览器可以接受的字符编码集。
实例：
         Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7
8、Content-Type
说明：
显示此HTTP请求提交的内容类型。一般只有post提交时才需要设置该属性。
实例：
         Content-type: application/x-www-form-urlencoded;charset:UTF-8
有关Content-Type属性值可以如下两种编码类型：
（1）“application/x-www-form-urlencoded”： 表单数据向服务器提交时所采用的编码类型，默认的缺省值就是“application/x-www-form-urlencoded”。 然而，在向服务器发送大量的文本、包含非ASCII字符的文本或二进制数据时这种编码方式效率很低。
（2）“multipart/form-data”： 在文件上载时，所使用的编码类型应当是“multipart/form-data”，它既可以发送文本数据，也支持二进制数据上载。
当提交为单单数据时，可以使用“application/x-www-form-urlencoded”；当提交的是文件时，就需要使用“multipart/form-data”编码类型。
在Content-Type属性当中还是指定提交内容的charset字符编码。一般不进行设置，它只是告诉web服务器post提交的数据采用的何种字符编码。
         一般在开发过程，是由前端工程与后端UI工程师商量好使用什么字符编码格式来post提交的，然后后端ui工程师按照固定的字符编码来解析提交的数据。所以这里设置的charset没有多大作用。
9、Connection
说明：
表示是否需要持久连接。如果web服务器端看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点， web服务器需要在返回给客户端HTTP头信息中发送一个Content-Length（返回信息正文的长度）头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然 后在正式写出内容之前计算它的大小。
实例：
Connection: keep-alive
10、Keep-Alive
说明：
         显示此HTTP连接的Keep-Alive时间。使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。
         以前HTTP请求是一站式连接，从HTTP/1.1协议之后，就有了长连接，即在规定的Keep-Alive时间内，连接是不会断开的。
实例：
Keep-Alive: 300
11、cookie
说明：
         HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。
12、Referer
说明：
包含一个URL，用户从该URL代表的页面出发访问当前请求的页面
·服务器端返回HTTP头部信息
1、Content-Length
说明：
         表示web服务器返回消息正文的长度
2、Content-Type:
说明：
         返回数据的类型（例如text/html文本类型）和字符编码格式。
实例：
Content-Type: text/html;charset=utf-8
3、Date
说明：
         显示当前的时间
你又了解 SPDY 吗？
答：是 Google 开发的基于传输控制协议 (TCP) 的应用层协议 ,开发组正在推动 SPDY 成为正式标准(现为互联网草案)。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级，以及HTTP包头压缩。谷歌已经开发一个网络服务器原型机，以及支持SPDY协议的Chrome浏览器版本。
作者: Swayer_Chen    时间: 2014-06-13 22:26
回复 33# hxksd


    你好，能解释以下关于put和post的区别吗？


我http的地方是在嵌入式开发中，用到post的地方不多，基本都是使用get/put，进行参数的set/get。

对于post的使用方式不是很清楚，我的理解感觉从功能实现上面post和put都差不多


因为我接触的onvif协议基本所有的方式都是使用的post但是和.cgi实现的功能差不多，而.cgi使用的基本就是get/put吧？


作者: Swayer_Chen    时间: 2014-06-13 22:32
各种浏览器对同一目的域名/地址可以同时保持几路长连接？
作者: lsstarboy    时间: 2014-06-14 19:43
最近主要写php的程序，并且做本地CDN服务器，系统用trafficserver，经常跟这些概念要交道。
顺便做个广告：TrafficServer是学习http非常好的一个平台，跟PHP不是一个级别的东西，特别是调试和写模块，不了解HTTP比较困难，要经常过去看rfc文档。里面大部分1.0和1.1的区别都做了相应的处理。

用nginx，在多级pass_proxy时遇到下级nginx不能实现基于域名的虚拟主机，并且记录不到客户端IP地址，仅记录到上一级nginx的IP，这时也要跟header们打交道，最常用的就是host和x-forward那一系列。

遇到比较奇葩的一件事，就是用php吐文件时，如果下载的文件名用utf-8编码，那么IE和FireFox会一个乱码一个不乱码，调了这个就乱了那个，仅输出charset是utf-8或者GB2312是不行的，只好用浏览器判断来解决，也只是解决大部分的情况，像360了之类的还是不好处理：

if ( strpos($_SERVER['HTTP_USER_AGENT'],"MSIE" ) ) $name = urlencode($name);
作者: lsstarboy    时间: 2014-06-14 19:48
回复 27# platinum


    印象中trafficserver里面专门对这件事做了处理，好让1.0的系统也用keep-alive，代码不是很确定，但文档中至少提到过。
作者: lsstarboy    时间: 2014-06-14 19:56
做过一个网页交流的小项目，当时有两个SPDY和websocket选项，感觉SPDY比较麻烦，最后选websocket了——虽然Google说过两者不冲突。
作者: T-Bagwell    时间: 2014-06-14 23:04
你了解 HTTP 吗？
接触过一点点，不是很深入的了解，一般就是用在http传输一些内容的时候用到
你认为你真的很了解 HTTP 吗？
了解的不多，一般就是用一点简单的header
你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
以下是刚刚了解到的，网上看的

  2. http 1.0与http1.1的区别如下：
  3. 下面主要从几个不同的方面介绍HTTP/1.0与HTTP/1.1之间的差别，当然，更多的内容是放在解释这种差异背后的机制上。
  4. 1 可扩展性
  5. 可扩展性的一个重要原则：如果HTTP的某个实现接收到了自身未定义的头域，将自动忽略它。
  6. 在消息中增加版本号，用于兼容性判断。注意，版本号只能用来判断逐段（hop-by-hop）的兼容性，而无法判断端到端（end-to-end）的兼容性。
  7. 例如，一台HTTP/1.1的源服务器从使用HTTP/1.1的Proxy那儿接收到一条转发的消息，实际上源服务器并不知道终端客户使用的是HTTP/1.0还是HTTP/1.1。因此，HTTP/1.1定义Via头域，用来记录消息转发的路径，它记录了整个路径上所有发送方使用的版本号。
  8. HTTP/1.1增加了OPTIONS方法，它允许客户端获取一个服务器支持的方法列表。
  9. 为了与未来的协议规范兼容，HTTP/1.1在请求消息中包含了Upgrade头域，通过该头域，客户端可以让服务器知道它能够支持的其它备用通信协议，服务器可以据此进行协议切换，使用备用协议与客户端进行通信。
  10. 2 缓存
  11. 在HTTP/1.0中，使用Expire头域来判断资源的fresh或stale，并使用条件请求（conditional request）来判断资源是否仍有效。例如，cache服务器通过If-Modified-Since头域向服务器验证资源的Last-Modefied头域是否有更新，源服务器可能返回304（Not Modified），则表明该对象仍有效；也可能返回200（OK）替换请求的Cache对象。
  12. 此外，HTTP/1.0中还定义了Pragma:no-cache头域，客户端使用该头域说明请求资源不能从cache中获取，而必须回源获取。
  13. HTTP/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。
  14. HTTP/1.0中，If-Modified-Since头域使用的是绝对时间戳，精确到秒，但使用绝对时间会带来不同机器上的时钟同步问题。而HTTP/1.1中引入了一个ETag头域用于重激活机制，它的值entity tag可以用来唯一的描述一个资源。请求消息中可以使用If-None-Match头域来匹配资源的entitytag是否有变化。
  15. 为了使caching机制更加灵活，HTTP/1.1增加了Cache-Control头域（请求消息和响应消息都可使用），它支持一个可扩展的指令子集：例如max-age指令支持相对时间戳；private和no-store指令禁止对象被缓存；no-transform阻止Proxy进行任何改变响应的行为。
  16. Cache使用关键字索引在磁盘中缓存的对象，在HTTP/1.0中使用资源的URL作为关键字。但可能存在不同的资源基于同一个URL的情况，要区别它们还需要客户端提供更多的信息，如Accept-Language和Accept-Charset头域。为了支持这种内容协商机制(content negotiation mechanism)，HTTP/1.1在响应消息中引入了Vary头域，该头域列出了请求消息中需要包含哪些头域用于内容协商。
  17. 3 带宽优化
  18. HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。
  19. HTTP/1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。
  20. 另外一种情况是请求消息中如果包含比较大的实体内容，但不确定服务器是否能够接收该请求（如是否有权限），此时若贸然发出带实体的请求，如果被拒绝也会浪费带宽。
  21. HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。注意，HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。
  22. 节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding是对消息进行端到端（end-to-end）的编码，它可能是资源在服务器上保存的固有格式（如jpeg图片格式）；在请求消息中加入Accept-Encoding头域，它可以告诉服务器客户端能够解码的编码方式。
  23. 而Transfer-Encoding是逐段式（hop-by-hop）的编码，如Chunked编码。在请求消息中加入TE头域用来告诉服务器能够接收的transfer-coding方式，
  24. 4 长连接
  25. HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。此外，由于大多数网页的流量都比较小，一次TCP连接很少能通过slow-start区，不利于提高带宽利用率。
  26. HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
  27. HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
  28. 在HTTP/1.0中，要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。同时，可以加入一些指令描述该长连接的属性，如max，timeout等。
  29. 事实上，Connection头域可以携带三种不同类型的符号：
  30. 1、一个包含若干个头域名的列表，声明仅限于一次hop连接的头域信息；
  31. 2、任意值，本次连接的非标准选项，如Keep-Alive等；
  32. 3、close值，表示消息传送完成之后关闭长连接；

  34. 客户端和源服务器之间的消息传递可能要经过很多中间节点的转发，这是一种逐跳传递（hop-by-hop）。HTTP/1.1相应地引入了hop-by-hop头域，这种头域仅作用于一次hop，而非整个传递路径。每一个中间节点（如Proxy，Gateway）接收到的消息中如果包含Connection头域，会查找Connection头域中的一个头域名列表，并在将消息转发给下一个节点之前先删除消息中这些头域。
  35. 通常，HTTP/1.0的Proxy不支持Connection头域，为了不让它们转发可能误导接收者的头域，协议规定所有出现在Connection头域中的头域名都将被忽略。
  36. 5 消息传递
  37. HTTP消息中可以包含任意长度的实体，通常它们使用Content-Length来给出消息结束标志。但是，对于很多动态产生的响应，只能通过缓冲完整的消息来判断消息的大小，但这样做会加大延迟。如果不使用长连接，还可以通过连接关闭的信号来判定一个消息的结束。
  38. HTTP/1.1中引入了Chunkedtransfer-coding来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。
  39. 在HTTP/1.0中，有一个Content-MD5的头域，要计算这个头域需要发送方缓冲完整个消息后才能进行。而HTTP/1.1中，采用chunked分块传递的消息在最后一个块（零长度）结束之后会再传递一个拖尾（trailer），它包含一个或多个头域，这些头域是发送方在传递完所有块之后再计算出值的。发送方会在消息中包含一个Trailer头域告诉接收方这个拖尾的存在。
  40. 6 Host头域
  41. 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
  42. HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。
  43. 7 错误提示
  44. HTTP/1.0中只定义了16个状态响应码，对错误或警告的提示不够具体。HTTP/1.1引入了一个Warning头域，增加对错误或警告信息的描述。
  45. 此外，在HTTP/1.1中新增了24个状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
  46. 8 内容协商
  47. 为了满足互联网使用不同母语和字符集的用户，一些网络资源有不同的语言版本（如中文版、英文版）。HTTP/1.0定义了内容协商（contentnegotiation）的概念，也就是说客户端可以告诉服务器自己可以接收以何种语言（或字符集）表示的资源。例如如果服务器不能明确客户端需要何种类型的资源，会返回300（Multiple Choices），并包含一个列表，用来声明该资源的不同可用版本，然后客户端在请求消息中包含Accept-Language和Accept-Charset头域指定需要的版本。
  48. 就像有些人会说几门外语，但每种外语的流利程度并不相同。类似地，网络资源也可以有不同的表达形式，比如有母语版和各种翻译版本。HTTP引入了一个品质因子（quality values）的概念来表示不同版本的可用性，它的取值从0.0到1.0。例如一个母语是英语的人也能讲法语、甚至还学了点丹麦语，那么他的浏览器可用作如下配置：Accept-Language: en, fr;q=0.5, da;q=0.1。这时，服务器会优先选取品质因子高的值对应的资源版本作为响应。

  50. 参考资料
  51. [1] Brian Totty, "HTTP: The DefinitiveGuide", O'REILLY & ASSOC INC, 27, Sep., 2002.
  52. [2] B. Krishnamurthy, J. C. Mogul, and D.M. Kristol, "Key Differences between HTTP/1.0 and HTTP/1.1", http://www2.research.att.com/~bala/papers/h0vh1.html.
复制代码
你知道各种 HTTP 返回码的实际意义吗？
返回码个人总结，大概分以下几个类型，细节的话我还得茶手册，renxiao已经写的很清楚了，我总结的类型：
2xx 成功的
3xx 跳转的
4xx 权限，文件找不到之类的错误
5xx 一般是执行脚本之类的错误，或者cgi错误，或者http内部错误之类的
希望以上没有总结错

你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
比如host ,refer, range,cache-control, content-length之类的，或者有的自己增加的字段
一般用wireshark抓包现看，实际内容实际分析，了解的就这么点东西
作者: tomac_cu    时间: 2014-06-14 23:37
我来说个今天的事儿吧，这个和http既靠边又不靠边，至少我到现在还没能确定到底出在什么方面。
环境：
服务端： linux + apache + php + mysql
客户端：ie chrome firefox safari
现象：
很简单的页面，加载特别慢。状态栏就是显示加载中。一般需要20秒左右。

分析过程：
1.调整服务器，加大prefork数量，减少可能的排队现象。
   结果：无改善

2.抓包：整个过程没有异常，没有拖尾包，有一些tcp重传，经分析与此无关
   结果：无结论

3.切分页面：把表格之类影响渲染的东西，改用div实现
   结果：无改善

4.资源切分：把各类src的慢慢去掉，看到哪里有提升
   结果: 是一个留用将来统计用的 <script>标签严重影响了速度
   处理：该脚本来源为某动态页面，目前暂未启用，所以直接返回空内容。
            通过wireshark可以看到socket关闭正常
            将这个标签去掉以后，页面秒开

结论：页面打开慢，可能是网络慢，脚本慢，也可能是不明原因的慢。至少这个问题我在http层上找了好久。
作者: platinum    时间: 2014-06-16 11:03
接下来大家可以讨论一下 HTTP 里所有方法的功能、价值及应用场景
常见的有 GET / POST
此外还有 CONNECT / HEAD
另外还有 TRACE / PUT / DELETE / OPTIONS
大家可以说一说
作者: hxksd    时间: 2014-06-20 14:57
1.GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

　　POST把提交的数据则放置在是HTTP包的包体中。

　　2."GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据，IIS4中最大为80KB，IIS5中为100KB"？？！

　　以上这句是我从其他文章转过来的，其实这样说是错误的，不准确的：

　　(1).首先是"GET方式提交的数据最多只能是1024字节"，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

　　注意这是限制是整个URL长度，而不仅仅是你的参数值数据长度。[见参考资料5]

　　(2).理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，说“POST数据量存在80K/100K的大小限制”是不准确的，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。

　　对于ASP程序，Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个限制。

　　由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制。我们还需要注意：

　　　　 1).IIS 6.0默认ASP POST数据量最大为200KB，每个表单域限制是100KB。
　　　　 2).IIS 6.0默认上传文件的最大大小是4MB。
　　　　 3).IIS 6.0默认最大请求头是16KB。
　　IIS 6.0之前没有这些限制。[见参考资料5]

　　所以上面的80K，100K可能只是默认值而已(注：关于IIS4和IIS5的参数，我还没有确认)，但肯定是可以自己设置的。由于每个版本的IIS对这些参数的默认值都不一样，具体请参考相关的IIS配置文档。

　　3.在ASP中，服务端获取GET请求参数用Request.QueryString，获取POST请求参数用Request.Form。在JSP中，用request.getParameter(\"XXXX\")来获取，虽然jsp中也有request.getQueryString()方法，但使用起来比较麻烦，比如：传一个test.jsp?name=hyddd&password=hyddd，用request.getQueryString()得到的是：name=hyddd&password=hyddd。在PHP中，可以用$_GET和$_POST分别获取GET和POST中的数据，而$_REQUEST则可以获取GET和POST两种请求中的数据。值得注意的是，JSP中使用request和PHP中使用$_REQUEST都会有隐患，这个下次再写个文章总结。

　　4.POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存，(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击
作者: linustd    时间: 2014-06-21 19:08
本帖最后由 linustd 于 2014-06-21 19:19 编辑

差点来晚了，本人谈一下HTTP。

先回答这几个问题：
1、你了解 HTTP 吗？
了解。
2、你认为你真的很了解 HTTP 吗？
起码不是新手
3、你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
http 1.0 和 1.1的最大区别就是HOST头，这个是用来实现虚拟主机的，也就是一个IP上，可以有多个网站，如果你的网站只是设置了通过HOST区分不同的虚拟主机，那么客户端通过IP访问是不行的。当然还有其它区别，keepalive等，这个不用多说。
4、你知道各种 HTTP 返回码的实际意义吗？
这个知道一些，只知道几个重要的就行，别的可以遇到时再查，
比如200成功，300跳转，其中301和302代表永久和临时跳转，在SEO方面很重要
5、你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
请求和相应header，基本上就是几行key-value对，服务器和客户端可以认识其中一些， 也可以不认识
6、你又了解 SPDY 吗？
不了解，好像是某公司组织又新搞的玩意，暂时用不着，学习使用技术的目的是为了生存，我反对为了技术而技术。用的着的时候在查资料也不晚。

其实我想说一点的是，我以前搞.net的，但是很多搞.net的人，别看每天都开发asp.net网站，对http协议和web标准根本一知半解，微软从来不注重这个，微软注重的只是通过不停的升级，套牢开发者和小企业赚钱。所以奉劝各位，如果有任何出路，千万别选择微软平台技术。

说到http，我想起一个重要的问题。很多资料，很多书，很多重要的书，甚至有可能你们这次要发的这本书里，都说到http协议是非连接的，也就是不能保持会话，必须通过cookie来认证用户。
其实这是非常错误的，http协议也是一个面向连接的协议，cookie就是实现会话的机制。
很多人忽视了一点，http协议是一个应用层协议，应用层协议的特点是，对底层的传输网络协议不知晓。
大家都想当然的想到tcp/ip协议，socket等，认为这些协议一旦连上，就可以持续的发送接受数据，好像建立了一层持久连接，但是这怎么可能，只不过是底层的网络链路层、会话层等帮你完成了保持会话的功能，网络又不是电话线，不可能一个连接占据整个线路。
HTTP协议是一个应用层协议，也就是说它可以用任何IPC来传递，比如pipe, socket, sharedmemory, 等等，既然http协议不一定通过socket， tcp/ip等传递，那你还有什么资格说http协议是非连接的呢？
从这一点说,http协议不仅仅是面向连接的，我们通常的socket程序，比如QQ、各种聊天程序，C/S等，试用socket来保持会话，也是错误的，因为你怎么知道我客户端和服务器一定会通过socket连连接呢？ 难道我不能自己发明一个协议，难道我不能用管道、共享内存来连接？
socket等，实际上也是文件，上层的通信协议，比如ＱＱ的协议，也应该像http协议一样，自己实现一个会话机制，而不能利用下层的socket来实现会话，因为那样，下层协议就不能对上层协议透明了。
所以，本人想说的是，千万不能再说http是非连接的协议了，它就是一个面向连接的协议。
作者: dlitchi    时间: 2014-06-25 23:55
我和HTTP打交道是在一个小工具开始的。一个关于webmail的工具，通过HTTP协议模拟浏览器来收取邮件。

    刚开始着手当然是对HTTP是一无所知的，后面就慢慢地通过google和baidu查找关于HTTP的的详解，大概了解了下，就开始写代码了。很庆幸的是，得益于阮一峰大哥博客www.ruanyifeng.com的推荐，我下载了fiddler。fiddler是一款windows平台强大的网络嗅探工具，有了它，所有通过浏览器发送和接收的HTTP报文你都可以一览无遗。它还可以对未发送出去和刚接收进来还没在浏览器上展示的报文拦截，你可以随意地修改它的报文内容，许多的web开发者利用它来对web项目进行调试，很方便易用。你完完全全可以照着它所拦截的报文格式来组包，编写代码，发送报文，接收报文，然后处理数据。

    在开始编码的过程中，其实本人对于HTTP报头的各个字段还不是非常理解的，只顾着照搬，然后组包、发包，就想着尽快结束掉这个小项目。可是当我信心满满的把我自认为完整的HTTP请求报文发送出去的时候，socket一直等到超时也没有返回数据给我。我打开浏览器，访问webmail地址，网络完全正常，我纳闷了。我对比了fiddler拦截的报文，一字不差呀。我寻思着，难道浏览器还隐藏了某些不可见的字符在报文中不成。后来，我把fiddler转换到一十六进制显示报文的选项卡，逐个字节对比。终于发现，我的HTTP请求报头中的末尾少了一个换行符‘\n’。 把缺少的换行符添加到我的报头末尾再次发送，这次服务器终于返回了数据。
    在得意自己解决了一个问题之后，不想又遇到了一个让我头疼的问题。我把服务器返回的数据去掉HTTP报文头部，查看过后居然是乱码。这次我傻眼了。 赶紧求助于万能的google和baidu，终于知道这是字符集搞的鬼。我查看了服务器返回的HTTP报头里边的Content-Type字段，它的值为“text/html; charset=utf-8”。"text/html"表明服务器返回的文件类型是html文件，"charset=utf-8"表明html文件内容采用的字符集是utf-8。这就意味着我需要转码，转成当前系统显示的字符集，才能看到HTTP正文内容。我继续对utf-8字符集进行深挖，后面也是得益于阮一峰的博客才了解了字符集的概念。
    当我在想这下经过转码应该可以看到真正的内容了吧，转了以后发现，数据不完整。 （又来了一个坑）经过了解，在HTTP应答报文中，一般都会出现"Content-Length"字段，以表明该为转码的HTTP正文内容的长度。可是，我并没有发现报头中有这个字段。倒是另外一个字段引起了我的注意，“Transfer-Encoding: chunked”。这个字段意味着这个HTTP正文内容的传输方式是分块传输。于是，再次查找分块传输的作用。终于，重见天日，正文内容一字不落的获取到了。
作者: platinum    时间: 2014-07-06 20:32
给大家推荐几个很好的 URL，由浅入深介绍一下 HTTP 协议

http://blog.csdn.net/hguisu/article/details/8680808
http://blog.csdn.net/hguisu/article/details/8683290
http://blog.csdn.net/hguisu/article/details/8608888
作者: send_linux    时间: 2014-07-06 22:24
platinum 发表于 2014-07-06 20:32
给大家推荐几个很好的 URL，由浅入深介绍一下 HTTP 协议

http://blog.csdn.net/hguisu/article/details/ ...



感谢白金，呵呵



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2