本文将详细介绍反向代理服务的概念以及如何利用反向代理服务器提高WEB服务器的性能和安全性。

　　一．反向代理的概念

　　什么是反向代理呢？其实，反向代理也就是通常所说的WEB服务器加速，它是一种通过在繁忙的WEB服务器和Internet之间增加一个高速的WEB缓冲服务器（即：WEB反向代理服务器）来降低实际的WEB服务器的负载。典型的结构如下图所示：

　　Web服务器加速（反向代理）是针对Web服务器提供加速功能的。它作为代理Cache，但并不针对浏 览器用户，而针对一台或多台特定Web服务器（这也是反向代理名称的由来）。实施反向代理（如上图所示），只要将Reverse Proxy Cache设备放置在一台或多台Web服务器前端即可。当互联网用户访问某个WEB服务器时，通过DNS服务器解析后的IP地址是Reverse Proxy Server的IP地址,而非原始Web服务器的IP地址,这时Reverse Proxy Server设备充当Web服务器，浏览器可以与它连接，无需再直接与Web服务器相连。因此，大量Web服务工作量被卸载到反向代理服务上。不但能够防 止外部网主机直接和web服务器直接通信带来的安全隐患，而且能够很大程度上减轻web服务器的负担，提高访问速度。

　　二．      反向代理和其它代理的比较

　　下面将对几种典型的代理服务作一个简单的比较。在网络上常见的代理服务器有三种：

　　1． 标准的代理缓冲服务器

　　一个标准的代理缓冲服务被用于缓存静态的网页（例如：html文件和图片文件等）到本地网络上的一台主机上（即代理服务器）。当被缓存的页面被第二次访问的时候，浏览器将直接从本地代理服务器那里获取请求数据而不再向原web站点请求数据。这样就节省了宝贵的网络带宽，而且提高了访问速度。但是，要想实现这种方式，必须在每一个内部主机的浏览器上明确指明代理服务器的IP地址和端口号。客户端上网时，每次都把请求送给代理服务器处理，代理服务器根据请求确定是否连接到远程web服务器获取数据。如果在本地缓冲区有目标文件，则直接将文件传给用户即可。如果没有的话则先取回文件，先在本地保存一份缓冲，然后将文件发给客户端浏览器。

　　2． 透明代理缓冲服务器

　　透明代理缓冲服务和标准代理服务器的功能完全相同。但是，代理操作对客户端的浏览器是透明的（即不需指 明代理服务器的IP和端口）。透明代理服务器阻断网络通信，并且过滤出访问外部的HTTP（80端口）流量。如果客户端的请求在本地有缓冲则将缓冲的数据 直接发给用户，如果在本地没有缓冲则向远程web服务器发出请求，其余操作和标准的代理服务器完全相同。对于Linux操作系统来说，透明代理使用 Iptables或者Ipchains实现。因为不需要对浏览器作任何设置，所以，透明代理对于ISP（Internet服务器提供商）特别有用。

　　3． 反向代理缓冲服务器

　　反向代理是和前两种代理完全不同的一种代理服务。使用它可以降低原始WEB服务器的负载。反向代理服务器承担了对原始WEB服务器的静态页面的请求，防止原始服务器过载。它位于本地WEB服务器和Internet之间，处理所有对WEB服务器的请求，阻止 了WEB服务器和Internet的直接通信。如果互联网用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。如果没有缓冲则先向WEB服务器发出请求，取回数据，本地缓存后再发送给用户。这种方式通过降低了向WEB服务器的请求数从而降低了WEB服务器的负载。

　　三．反向代理工作原理

　　反向代理服务器位于本地WEB服务器和Internet之间,如下图所示：

　　当用户浏览器发出一个HTTP请求时，通过域名解析将请求定向到反向代理服务器（如果要实现多个WEB 服务器的反向代理，需要将多个WEB服务器的域名都指向反向代理服务器）。由反向代理服务器处理器请求。反向代理一般只缓存可缓冲的数据（比如html网 页和图片等），而一些CGI脚本程序或者ASP之类的程序不缓存。它根据从WEB服务器返回的HTTP头标记来缓冲静态页面。有四个最重要HTTP头标 记：

• Last-Modified: 告诉反向代理页面什么时间被修改
• Expires: 告诉反向代理页面什么时间应该从缓冲区中删除
• Cache-Control: 告诉反向代理页面是否应该被缓冲
• Pragma: 告诉反向代理页面是否应该被缓冲.

例如：在默认情况下，ASP页面返回” Cache-control: private.” ，所以ASP页面时不会在反向代理服务器缓存的

     反向代理服务器（Reverse Proxy Server）一般被置于源服务器的前端，如图中所示。它配备有大容量的内存和高速磁盘，用于缓存客户的请求，所以反向代理服务器又称为加速服务器。

图:反向代理服务器

    对于客户送过来的请求，反向代理服务器的工作方式如下：

·            使用反向代理服务器后，客户端送过来的请求会首先送到反向代理服务器。

·            反向代理服务器先查自己缓存的内容（动态内容或静态内容）。

·            如果客户请求内容在缓存中，则直接将结果反馈给客户，此次请求完成。

·            如果客户请求内容不在缓存中，它会根据后面的各个HTTP服务器（或内容服务器）的运行情况，做负载均衡处理，将请求进一步送到某个http 服务器（或内容服务器）。

·            后端服务器作处理后，反馈结果给反向代理服务器。

·            对于后端服务器反馈过来的结果，它会将结果缓存（动态内容或静态内容）起来，并进一步送给客户端，此次请求完成。

    反向代理服务器通常要为一个请求同时维护两个会话：与客户端的会话和与后端服务器的对话。和普通的代理不同，反向代理服务器一般只代理一台或者有限的几台服务器，对于客户而言，反向代理服务器对于他们就相当于源服务器，对于源服务器而言，反向代理服务器通常就是唯一的客户，因为一般客户不和源服务器直接通信。典型情况下，源服务器对于客户或者客户对于源服务器，都是不可见的。

反向代理服务器的作用

    代理服务器起着客户机中继站的作用。它转发请求并接收响应，这使它成为高速缓存结果以便重用的理想场所。这类代理服务器称为高速缓存代理，它具有以下作用：

·            加快对客户的响应时间，减轻后端源服务器（即内容服务器）负载

    使用反向代理服务器后，由于它具有大容量缓存，可以缓存多个静态/动态页面，当有客户请求送过来时，如能够直接在缓存中找到请求结果，就可以直接反馈给客户，而不用再将请求送给后端服务器。这样就加快了对客户的响应时间，同时也减轻了后端源服务器的负载。

·            保障后端源服务器（即内容服务器）的安全

    对Internet上的客户端而言，它只能接触到反向代理服务器，因此反向代理服务器就成为后端服务器的屏障，保障了后端服务器的安全。

·            减少源服务器（即内容服务器）节点之间占用的网络带宽

    使用反向代理服务器后，它具有的大容量缓存可以减少源服务器的网络通讯量。这样就减少源服务器（即内容服务器）节点之间占用的网络带宽。

·            对源服务器进行负载均衡(Load Balance)。

    当后端源服务器有多个时，反向代理服务器可以根据后端各个服务器当前负载情况，做负载均衡处理，有选择的将当前请求送给最空闲的后端服务器。

就是在timeout时间内又有新的连接过来，同时max会自动减1，直到为0，强制断掉。见下面的四个图，注意看Date的值（前后时间差都是在5秒之内）！

从HTTP的角度

1 客户端 在http Request  Header上带上 Accept-Encoding:gzip,deflate

2服务器若是支持gzip压缩则在http reponse eader

部分返回Content-Encoding: gzip 或者Content-Type: application/x-gzip

3将body部分用gzip解压缩 则得到网页内容.

传说中ie有bug 在处理js css压缩的时候有bug,我不理解 挺简单的怎么会有bug呢.

从gzip的角度

gzip是一种数据格式 默认且目前仅使用deflate算法压缩data部分

zlib也是一种数据格式,使用defalte算法压缩数据部分.

deflate是一种压缩算法,是huffman编码的一种加强

zlib是一个开源库, 提供deflate压缩和对应的infalte解压缩.

不过zlib默认的deflate infalte默认是处理zlib格式数据.必须使用

deflateInit2(&strm, DEFAULT_COMPRESSION,Z_DEFLATED, DEFAULT_WINDOWSIZE,DEFAULT_MEMLEVEL, Z_DEFAULT_STRATEGY);

初始化才是处理raw deflate data.(这一点在zlib manul没有提,在faq中提到,困扰了我好久,还是同事L帮我调试发现)

至于gzip格式解析 对着RFC写就可以了.

参见RFC 1950 关于zlib http://www.faqs.org/rfcs/rfc1950.html

      RFC 1951 关于deflate http://www.faqs.org/rfcs/rfc1951.html

      RFC 1952 关于gzip http://www.faqs.org/rfcs/rfc1952.html 

nt  CGzip::Ungzip(const std::string & inStr , std::string &outStr){
    static int nFileCount=0;
        nFileCount++;
    string strZipFileName="test";
//    CConvert::StrToFile(inStr,strZipFileName+CConvert::toString<int>(nFileCount)+"H.gzip";
    if(inStr.length()<11){
        return -1;   
    }
    //process gzip header
    unsigned int skipCt = 10;
    unsigned int skipZeroCt = 0;
    unsigned char ID1 = inStr[0];
    unsigned char ID2 = inStr[1];
    unsigned char XFL=inStr[8];
    bool bFEXTRA = false ;
    bool bFNAME = false ;
    bool bFCOMMENT = false ;
    bool bFHCRC = false ;
    unsigned int XLEN = 0;
   
    if( (ID1!=31) && (ID2!=139)){
        return -1;  //非gzip头部
        }
    unsigned char CM = inStr[2];
    if(CM!={
        return -1; //现在都只处理 deflate压缩的
    }
    unsigned char FLG = inStr[3];
    if( (FLG & GZIP_HEAD_FEXTRA) != 0){
        bFEXTRA = true ;
        skipCt += 2;
        XLEN = inStr[10]+ inStr[11]*256 ;//按照小端字节序列处理
        skipCt += XLEN;
    }
    if( (FLG & GZIP_HEAD_FNAME) != 0){
        bFNAME = true;
        skipZeroCt++;
    }
    if( (FLG & GZIP_HEAD_FCOMMENT) != 0){
        bFCOMMENT = true;
        skipZeroCt++;   
    }
   
    size_t passedZeroCt = 0;
   
    size_t iStep = skipCt ;
    for( size_t iStep =  skipCt ; iStep<inStr.length(); iStep++){
            if(passedZeroCt>=skipZeroCt){
                break;   
            }
            if(inStr[iStep]==''{
                passedZeroCt++;   
            }
       
    }
    skipCt = iStep ;
    if( (FLG & GZIP_HEAD_FHCRC) != 0){
        bFHCRC = true;
        skipCt+=2 ;
    }
        string coreStr = inStr.substr(skipCt,inStr.length()-8-skipCt);
           return CGzip::Inflate(coreStr,outStr);
   
   
   
}

int  CGzip:ogzip(const std::string & inStr , std::string &outStr){
    char pAddHead[10];
    unsigned long crc = 0;
    // gzip header
    static const char deflate_magic[2] = {'37', '\213'};
    snprintf(pAddHead, 10,
            "%c%c%c%c%c%c%c%c%c%c", deflate_magic[0],
            deflate_magic[1], Z_DEFLATED, 0 /* flags */,
            0, 0, 0, 0 /* 4 chars for mtime */,
            0 /* xflags */, 0xff);
    string addHead(pAddHead,10);
    //gzip's raw deflate body
    if(CGzip:eflate(inStr,outStr)<0){
        return - 1;   
    }
    //gzip trailer
    crc = crc32(crc, (const Bytef*)inStr.data(), inStr.length());
    char  tailBuf[8];
    memcpy(tailBuf, &crc, 4);
    int isize=inStr.size();
    memcpy(tailBuf,&isize,4);
    string tailStr(tailBuf , 8 );
    outStr = addHead + outStr+tailStr;     //
    return outStr.length(); //

消息：HTTP协议中顶级数据单位，使用HTTP协议通信的机器之间来回发送的数据包

实体：只出现在有消息体的消息中。它按照实体header定义的格式和编码进行传输。

方法：

OPTIONS ：客户端查询服务器对与某URL允许的通信选项

GET ：从服务器获取URL对应的资源

HEAD ：除了服务器响应中不能包含消息体，该方法与GET一样。用于只需少数元信息的情况

POST ：被设计用来注解、修改URL所对应的资源

PUT ：被设计用来修改或创建资源。当URL对应的资源存在时，则提交的作为新版本，否则新建资源

DELETE ：被设计用来删除URL对应的资源

TRACE ：主要用来测试。服务器将最终接收到的请求本身发送回来，作为客户端诊断依据

CONNECT ：保留的方法名，用于代理切换隧道

header特殊参数：

q ：在大多的各种header值中，都可以看到一个名为q=0.2、q=0.7之类的参数。因为发送header主要是一个和服务器的协商过程，所以能允许的选项一般不只一个，但具体哪个优先呢？这就需要为一些选项制定权重值。q参数的值是一个从0到1的浮点数，默认是1，为0表示客户端无法接收，小数点后 不能超过3位。另外，header的多个值之间用逗号分隔而不是分号。比如这个header：Accept:audio/*;q=0.2,audio /basic，这表示客户端告诉服务器“我最喜欢的是一个audio/basic类型的音频(因为它没有设置q参数，默认是1），但如果没有，给我一个任 意类型(audio/*)的音频也行”。当然，这只是q参数一个比较简单的应用。

常规header ：

Cache-Control ：用于指出请求/响应链上所有缓存必须服从的指令，它必须具有穿透各代理和网关的能力。HTTP1.0可能不支持该header和Pragma：no-cache。

Connection ：允许客户端指出希望特定连接的选项，且禁止由代理在将来的连接中通讯

Date ：表示消息发生的日期和时间，与RFC 822中的orig-date语义一致

Pragma ：用来包括实现特定的指令，可能应用到请求/响应链上所有接收方  

Trailer ：指出给出的头部域集合在以chunked transfer-coding编码的消息的尾部中存在

Transfer-Encoding ：指出应用什么类型的转换到消息主体上，与content-coding不同，这不是指定实体的属性而是消息的

Upgrade ：允许客户端指出其支持的其他通讯协议，切愿意使用之，若服务器发现切换是可行的，必须在响应中回101

Via ：必须由网关或代理来指出请求中的UA和服务器、以及在响应中的原始服务器和客户端的中间协议和接收方。用于跟踪消息转发，避免请求循环

Warning ：用户携带关于消息的状态和转换的额外信息，可能不在消息中反映。一般用于警告应用到消息实体上的缓存操作或转换缺少语义透明度

请求header：

Accept ：客户端指出响应可以接受的媒体类型             

Accept-Charset ：客户端指出响应可以接受的字符集

Accept-Encoding ：客户端指出响应可以接受的字符编码

Accept-Language ：客户端指出允许的语言     

Authorization ：客户端在受到401后，需要向服务器标明身份，包括此header即可      

Expect : 客户端指出要求的特殊服务器行为。若服务器无法满足，可以返回417            

From :               

Host : 客户端指出要请求的资源的因特网主机和端口号              

If-Match : 用于与方法一起使其条件化          

If-Modified-Since : 用于方法使其条件化，如果请求的变量在本域指定的时间从来不曾修改过，则实体将不会从服务器返回，改为304

If-None-Match : 用于与方法一起使其条件化     

If-Range : 用于与方法一起使其条件化          

If-Unmodified-Since : 用于与方法一起使其条件化，如果请求的资源自header值时间以来未改变，则服务器执行该请求

Max-Forwards : 提供某种机制，TRACE和OPTIONS方法用来限制可以转发给下个入界服务器代理或网关的数量，相当于客户端跟踪请求链      

Proxy-Authorization : 允许客户端向代理标识自己，该代理需要认证

Range : 字节范围，可以指定单个实体中单个字节范围或范围集             

Referer : 允许服务器为感兴趣的资源、日志、优化缓存等生成向后链接清单           

TE : 指出愿意在响应中接受任何扩展的transfer-coding                

User-Agent : 包含发起请求的用户代理（浏览器和OS）的信息

响应header：

Accept-Ranges ：服务器指出对请求的资源可接受的范围，可以是字节数或none      

Age ：HTTP使用改header来传输从缓存服务器获取时的响应消息的估计年龄，是缓存服务器估计从响应产生或被原始服务器重新证实以来的总时间          

ETag ：提供所请求的实体标签的当前值              

Location ：用来重定向接收

方到非URI的位置来完成请求。对于201，Location是由请求创建的新资源的标识          

Proxy-Authenticate ：该header必须作为407响应的一部分，指出认证方案和可应用到代理的URI上的参数

Retry-After ：能与503响应一起用于指出希望该服务对客户端可以维持多久，       

Server ：指出服务器使用的软件信息            

Vary ：              

WWW-Authenticate ：必须包括在401中，值至少有challenge组成，它指出认证方案和可应用到URI的参数  

实体header：

Allow ：客户端指出对URI的资源允许的方法              

Content-Encoding : 用作对media-type的修饰符，其值将必须应用到实体body上的额外内容编码。主要用来允许压缩而不丢失下层媒体类型标识  

Content-Language : 客户端指出自己所选的语言，指出目标观众对所封装实体的自然语言。这可能与实体body内所有语言相同  

Content-Length ：指出实体body按十进制数的字节流的尺寸     

Content-Location ：如果实体能从独立于请求URI的位置访问，则服务器可以提供该实体自己的位置   

Content-MD5 ：是实体body的MD5摘要，以便提供端到端的完整性检查        

Content-Range ：与实体body的一部分一起发送，用来指定该部分body应用到全部body的哪个地方      

Content-Type ：指出发送给接收方的实体body的媒体类型，媒体类型参见IANA       

Expires ：指出响应被认为过期的日期/时间            

Last-Modified ：指出原始服务器认为该变量最后修改的日期和时间，确实意思取决于原是服务器的实现和资源的属性。对文件，可能只是文件系统内最后修改时间

extension-header ：

状态码：

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

307 : Temporary Redirect

400 : Bad Request

401 : Unauthorized

402 : Payment Required

403 : Forbidden

404 : Not Found

405 : Method Not Allowed

406 : Not Acceptable

407 : Proxy Authentication Required

408 : Request Time-out

409 : Conflict

410 : Gone

411 : Length Required

412 : Precondition Failed

413 : Request Entity Too Large

414 : Request-URI Too Large

415 : Unsupported Media Type

416 : Requested range not satisfiable

417 : Expectation Failed

500 : Internal Server Error

501 : Not Implemented

502 : Bad Gateway

503 : Service Unavailable

504 : Gateway Time-out

505 : HTTP Version not supported

extension-code

关键字：HTTP

对应URL:D:\New HY Code\HY Web Server\Debug\hy web root\Henyep\UploadFile

对应URL:D:\UploadFile

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。
每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。

1、普通报头
在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。
eg：
Cache-Control 用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。
请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
eg：为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序可以编写如下：response.sehHeader("Cache-Control","no-cache");
//response.setHeader("Pragma","no-cache");作用相当于上述代码，通常两者//合用
这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache

Date普通报头域表示消息产生的日期和时间

Connection普通报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭连接

2、请求报头
请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。
常用的请求报头
Accept
Accept请求报头域用于指定客户端接受哪些类型的信息。eg：Accept：image/gif，表明客户端希望接受GIF图象格式的资源；Accept：text/html，表明客户端希望接受html文本。
Accept-Charset
Accept-Charset请求报头域用于指定客户端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。eg：Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。
Accept-Language
Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。eg：Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。
Authorization
Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。
Host（发送请求时，该报头域是必需的）
Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，eg：
我们在浏览器中输入：http://www.guet.edu.cn/index.html
浏览器发送的请求消息中，就会包含Host请求报头域，如下：
Host：www.guet.edu.cn
此处使用缺省端口号80，若指定了端口号，则变成：Host：www.guet.edu.cn:指定端口号
User-Agent
我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。
请求报头举例：
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)

3、响应报头
响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。
常用的响应报头
Location
Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。
Server
Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是
Server响应报头域的一个例子：
Server：Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。
eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服务器对请求资源采用的是基本验证机制。
Content-Disposition就是当用户想把请求所得的内容存为一个文件的时候提供一个默认的文件名。具体的定义如下 Content-Disposition: attachment; filename=“filename.xls”
当然filename参数可以包含路径信息，但User-Agnet会忽略掉这些信息，只会把路径信息的最后一部分做为文件名。当你在响应类型为application/octet- stream情况下使用了这个头信息的话，那就意味着你不想直接显示内容，而是弹出一个”文件下载”的对话框，接下来就是由你来决定“打开”还是“保存”了。

4、实体报头
请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。
常用的实体报头
Content-Encoding
Content -Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，eg：Content-Encoding： gzip
Content-Language
Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读
者。eg：Content-Language:da
Content-Length
Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。
Content-Type
Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg：
Content-Type:text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
Last-Modified
Last-Modified实体报头域用于指示资源的最后修改日期和时间。
Expires
Expires 实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT
HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。eg：为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置为0，jsp中程序如下：response.setDateHeader("Expires","0");

但凡搞WEB开发的人都离不开HTTP（超文本传输协议），而要了解HTTP，除了HTML本身以外，还有一部分不可忽视的就是HTTP消息头。
做过Socket编程的人都知道，当我们设计一个通信协议时，“消息头/消息体”的分割方式是很常用的，消息头告诉对方这个消息是干什么的，消息体告诉对方怎么干。HTTP传输的消息也是这样规定的，每一个HTTP包都分为HTTP头和HTTP体两部分，后者是可选的，而前者是必须的。每当我们打开一个网页，在上面点击右键，选择“查看源文件”，这时看到的HTML代码就是HTTP的消息体，那么消息头又在哪呢？IE浏览器不让我们看到这部分，但我们可以 通过截取数据包等方法看到它。
下面就来看一个简单的例子：
首先制作一个非常简单的网页，它的内容只有一行：
<html><body>hello world</body></html>
把它放到WEB服务器上，比如IIS，然后用IE浏览器请求这个页面（http://localhost:8080/simple.htm），当我们请求这个页面时，浏览器实际做了以下四项工作：
1 解析我们输入的地址，从中分解出协议名、主机名、端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下：
协议名：http
主机名：localhost
端口：8080
对象路径：/simple.htm
2 把以上部分结合本机自己的信息，封装成一个HTTP请求数据包
3 使用TCP协议连接到主机的指定端口（localhost, 8080），并发送已封装好的数据包
4 等待服务器返回数据，并解析返回数据，最后显示出来
由截取到的数据包我们不难发现浏览器生成的HTTP数据包的内容如下：
GET /simple.htm HTTP/1.1<CR>
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*<CR>
Accept-Language: zh-cn<CR>
Accept-Encoding: gzip, deflate<CR>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)<CR>
Host: localhost:8080<CR>
Connection: Keep-Alive<CR>
<CR>
为了显示清楚我把所有的回车的地方都加上了“<CR>”，注意最后还有一个空行加一个回车，这个空行正是HTTP规定的消息头和消息体的分界线，第一个空行以下的内容就是消息体，这个请求数据包是没有消息体的。
消息的第一行“GET”表示我们所使用的HTTP动作，其他可能的还有“POST”等，GET的消息没有消息体，而POST消息是有消息体的，消息体的内容就是要POST的数据。后面/simple.htm就是我们要请求的对象，之后HTTP1.1表示使用的是HTTP1.1协议。
第二行表示我们所用的浏览器能接受的Content-type，三四两行则是语言和编码信息，第五行显示出本机的相关系信息，包括浏览器类型、操作系统信息等，很多网站可以显示出你所使用的浏览器和操作系统版本，就是因为可以从这里获取到这些信息。
第六行表示我们所请求的主机和端口，第七行表示使用Keep-Alive方式，即数据传递完并不立即关闭连接。
服务器接收到这样的数据包以后会根据其内容做相应的处理，例如查找有没有“/simple.htm”这个对象，如果有，根据服务器的设置来决定如何处理，如果是HTM，则不需要什么复杂的处理，直接返回其内容即可。但在直接返回之前，还需要加上HTTP消息头。
服务器发回的完整HTTP消息如下：
HTTP/1.1 200 OK<CR>
Server: Microsoft-IIS/5.1<CR>
X-Powered-By: ASP.NET<CR>
Date: Fri, 03 Mar 2006 06:34:03 GMT<CR>
Content-Type: text/html<CR>
Accept-Ranges: bytes<CR>
Last-Modified: Fri, 03 Mar 2006 06:33:18 GMT<CR>
ETag: "5ca4f75b8c3ec61:9ee"<CR>
Content-Length: 37<CR>
<CR>
<html><body>hello world</body></html>
同样，我用“<CR>”来表示回车。可以看到，这个消息也是用空行切分成消息头和消息体两部分，消息体的部分正是我们前面写好的HTML代码。
消息头第一行“HTTP/1.1”也是表示所使用的协议，后面的“200 OK”是HTTP返回代码，200就表示操作成功，还有其他常见的如404表示对象未找到，500表示服务器错误，403表示不能浏览目录等等。
第二行表示这个服务器使用的WEB服务器软件，这里是IIS 5.1。第三行是ASP.Net的一个附加提示，没什么实际用处。第四行是处理此请求的时间。第五行就是所返回的消息的content-type，浏览器 会根据它来决定如何处理消息体里面的内容，例如这里是text/html，那么浏览器就会启用HTML解析器来处理它，如果是image/jpeg，那么 就会使用JPEG的解码器来处理。
消息头最后一行“Content-Length”表示消息体的长度，从空行以后的内容算起，以字节为单位，浏览器接收到它所指定的字节数的内容以后就会认为这个消息已经被完整接收了。

理解HTTP消息头 （二）

常见的HTTP返回码

上一篇文章里我简要的说了说HTTP消息头的格式，注意到在服务器返回的HTTP消息头里有一个“HTTP/1.1 200 OK”，这里的200是HTTP规定的返回代码，表示请求已经被正常处理完成。浏览器通过这个返回代码就可以知道服务器对所发请求的处理情况是什么，每一种返回代码都有自己的含义。这里列举几种常见的返回码。

1 403 Access Forbidden

如果我们试图请求服务器上一个文件夹，而在WEB服务器上这个文件夹并没有允许对这个文件夹列目录的话，就会返回这个代码。一个完整的403回复可能是这样的：（IIS5.1）
HTTP/1.1 403 Access Forbidden
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 08:57:39 GMT
Connection: close
Content-Type: text/html
Content-Length: 172

<html><head><title>Directory Listing Denied</title></head>
<body><h1>Directory Listing Denied</h1>This Virtual Directory does not allow contents to be listed.</body></html>

2 404 Object not found

当我们请求的对象在服务器上并不存在时，就会给出这个返回代码，这可能也是最常见的错误代码了。IIS给出的404消息内容很长，除了消息头以外还有一个完整的说明“为什么会这样”的网页。APACHE服务器的404消息比较简短，如下：
HTTP/1.1 404 Not Found
Date: Mon, 06 Mar 2006 09:03:14 GMT
Server: Apache/2.0.55 (Unix) PHP/5.0.5
Content-Length: 291
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /notexist was not found on this server.</p>
<hr>
<address>Apache/2.0.55 (Unix) PHP/5.0.5 Server at localhost Port 8080</address>
</body></html>

也许你会问，无论是404还是200，都会在消息体内给出一个说明网页，那么对于客户端来说二者有什么区别呢？一个比较明显的区别在于200是 成功请求，浏览器会记录下这个地址，以便下次再访问时可以自动提示该地址，而404是失败请求，浏览器只会显示出返回的页面内容，并不会记录此地址，要再次访问时还需要输入完整的地址。

3 401 Access Denied

当WEB服务器不允许匿名访问，而我们又没有提供正确的用户名/密码时，服务器就会给出这个返回代码。在IIS中，设置IIS的安全属性为不允许匿名访问（如下图），此时直接访问的话就会得到以下返回结果：

HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 09:15:55 GMT
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Connection: close
Content-Length: 3964
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html dir=ltr>
……
此时浏览器上给出的提示如下图，让我们输入用户名和密码：

因返回信息中消息体较长，只取前面两行内容。注意，如果是用localhost来访问本机的IIS，因IE可以直接取得当前用户的身份，它会和服务器间直接进行协商，所以不会看到401提示。
当我们在输入了用户名和密码以后，服务器与客户端会再进行两次对话。首先客户端向服务器索取一个公钥，服务器端会返回一个公钥，二者都用BASE64编码，相应的消息如下（编码部分已经做了处理）：

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: 192.168.0.55:8080
Connection: Keep-Alive
Authorization: Negotiate ABCDEFG……

HTTP/1.1 401 Access Denied
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 09:20:53 GMT
WWW-Authenticate: Negotiate HIJKLMN……
Content-Length: 3715
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html dir=ltr>
……
客户端拿到公钥之后使用公钥对用户名和密码进行加密码，然后把加密以后的结果重新发给服务器：
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: 192.168.0.55:8080
Connection: Keep-Alive
Authorization: Negotiate OPQRST……

这样，如果验证通过，服务器端就会把请求的内容发送过来了，也就是说禁止匿名访问的网站会经过三次请求才可以看到页面。但因为客户端浏览器已经缓存了公钥，用同一个浏览器窗口再次请求这个网站上的其它页面时就可以直接发送验证信息，从而一次交互就可以完成了。

4 302 Object Moved

用过ASP的人都知道ASP中页面重定向至少有Redirect和Transfer两种方法。二的区别在于Redirect是客户端重定向，而Transfer是服务器端重定向，那么它们具体是如何通过HTTP消息头实现的呢？
先来看一下Transfer的例子：
例如ASP文件1.asp只有一行
<% Server.Transfer "1.htm" %>
HTML文件1.htm也只有一行：
<p>this is 1.htm</p>
如果我们从浏览器里请求1.asp，发送的请求是：
GET /1.asp HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Connection: Keep-Alive
Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP

注意请求的文件确实是1.asp，而得到的回应则是：
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 12:52:44 GMT
X-Powered-By: ASP.NET
Content-Length: 20
Content-Type: text/html
Cache-control: private

<p>this is 1.htm</p>
不难看出，通过Server.Transfer语句服务器端已经做了页面重定向，而客户端对此一无所知，表面上看上去得到的就是1.asp的结果。
如果把1.asp的内容改为：
<% Response.Redirect "1.htm" %>
再次请求1.asp，发送的请求没有变化，得到的回应却变成了：
HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 12:55:57 GMT
X-Powered-By: ASP.NET
Location: 1.htm
Content-Length: 121
Content-Type: text/html
Cache-control: private

<head><title>Object moved</title></head>
<body><h1>Object Moved</h1>This object may be found <a HREF="">here</a>.</body>

注意HTTP的返回代码由200变成了302，表示这是一个重定向消息，客户端需要根据消息头中Location字段的值重新发送请求，于是就有了下面一组对话：
GET /1.htm HTTP/1.1
Accept: */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Connection: Keep-Alive
If-Modified-Since: Thu, 02 Mar 2006 06:50:13 GMT
If-None-Match: "b224758ec53dc61:9f0"
Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Date: Mon, 06 Mar 2006 12:55:57 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Mon, 06 Mar 2006 12:52:32 GMT
ETag: "76d85bd51c41c61:9f0"
Content-Length: 20

<p>this is 1.htm</p>
很明显，两种重定向方式虽然看上去结果很像，但在实现原理上有很大的不同。

5 500 Internal Server Error

500号错误发生在服务器程序有错误的时候，例如，ASP程序为
<% if %>
显然这个程序并不完整，于是得到的结果为：
HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/5.1
Date: Mon, 06 Mar 2006 12:58:55 GMT
X-Powered-By: ASP.NET
Content-Length: 4301
Content-Type: text/html
Expires: Mon, 06 Mar 2006 12:58:55 GMT
Set-Cookie: ASPSESSIONIDACCTRTTT=ALKDJOPBPPKNPCNOEPCNOOPD; path=/
Cache-control: private

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html dir=ltr>
……

服务器发送了500号错误，并且后面通过HTML的方式说明了错误的原因。

理解HTTP消息头 （三）

（三） 客户端发送的内容
这一次主要来观察HTTP消息头中客户端的请求，从中找到一些有意思的内容。

1 HTTP_REFERER
写两个简单的网页：
a.htm：
<a href=b.htm>to page b</a>
b.htm：
haha
内容很简单，就是网页A中有一个到B的链接。把它们放到IIS上，并访问网页A，从中再点击到B的链接，于是看到了B页的“haha”。那么这两次请求有什么不同吗？观察它们所发送的HTTP消息头，最明显的区别就是访问B页时比访问A页时多了一行：
Referer: http://localhost/a.htm
这一行就表示，用户要访问的B页是从A页链接过来的。
服务器端要想取得这个值也是很容易的，以ASP为例，只需要写一句
<% =Request.ServerVariables("HTTP_REFERER") %>
就可以了。
一些网站通过HTTP_REFERER来做安全验证，判断用户是不是从允许的页面链接来的，而不是直接从浏览器上打URL或从其他页面链接过来，这样可以 从一定程度上防止网页被做非法使用。但从上述原理来看，想要骗过服务器也并不困难，只要手工构造输入的HTTP消息头就可以了，其他常用的手段还有通过 HOSTS文件伪造域名等。
除了超链接以外，还有其他几种方式会导致HTTP_REFERER信息被发送，如：
内联框架：<iframe src=b.asp></iframe>
框架集：<frameset><frame src=b.asp></frameset>
表单提交：<form action=b.asp><input type=submit></form>
SCRIPT引用：<script src=b.asp></script>
CSS引用：<link rel=stylesheet type=text/css href=b.asp>
XML数据岛：<xml src=b.asp></xml>

而以下形式不会发送HTTP_REFERER：
script转向：<script>location.href="b.asp"</script>
script开新窗口：<script>window.open("b.asp");</script>
META转向：<meta http-equiv="refresh" content="0;URL=b.asp">
引入图片：<img src=b.asp>

2 COOKIE
COOKIE是大家都非常熟悉的了，通过它可以在客户端保存用户状态，即使用户关闭浏览器也能继续保存。那么客户端与服务器端是如何交换COOKIE信息的呢？没错，也是通过HTTP消息头。
首先写一个简单的ASP网页：
<%
Dim i
i = Request.Cookies("key")
Response.Write i
Response.Cookies("key") = "haha"
Response.Cookies("key").Expires = #2007-1-1#
%>
第一次访问此网页时，屏幕上一片白，第二次访问时，则会显示出“haha”。通过阅读程序不难发现，屏幕上显示的内容实际上是COOKIE 的内容，而第一次访问时还没有设置COOKIE的值，所以不会有显示，第二次显示的是第一次设置的值。那么对应的HTTP消息头应该是什么样的呢？
第一次请求时没什么不同，略过
第一次返回时消息内容多了下面这一行：
Set-Cookie: key=haha; expires=Sun, 31-Dec-2006 16:00:00 GMT; path=/
很明显，key=haha表示键名为“key”的COOKIE的值为“haha”，后面是这则COOKIE的过期时间，因为我用的中文操作系统的时区是东八区，2007年1月1日0点对应的GMT时间就是2006年12月31日16点。
第二次再访问此网页时，发送的内容多了如下一行：
Cookie: key=haha
它的内容就是刚才设的COOKIE的内容。可见，客户端在从服务器端得到COOKIE值以后就保存在硬盘上，再次访问时就会把它发送到服务器。发送时并没有发送过期时间，因为服务器对过期时间并不关心，当COOKIE过期后浏览器就不会再发送它了。
如果使用IE6.0浏览器并且禁用COOKIE功能，可以发现服务器端的set-cookie还是有的，但客户端并不会接受它，也不会发送它。有些网站， 特别是在线投票网站通过记录COOKIE防止用户重复投票，破解很简单，只要用IE6浏览器并禁用COOKIE就可以了。也有的网站通过COOKIE值为 某值来判断用户是否合法，这种判断也非常容易通过手工构造HTTP消息头来欺骗，当然用HOSTS的方式也是可以欺骗的。

3 SESSION
HTTP协议本身是无状态的，服务器和客户端都不保证用户访问期间连接会一直保持，事实上保持连接是HTTP1.1才有的新内容，当客户端发送的消息头中有“Connection: Keep-Alive” 时表示客户端浏览器支持保持连接的工作方式，但这个连接也会在一段时间没有请求后自动断开，以节省服务器资源。为了在服务器端维持用户状态，SESSION就被发明出来了，现在各主流的动态网页制做工具都支持SESSION，但支持的方式不完全相同，以下皆以ASP为例。
当用户请求一个ASP网页时，在返回的HTTP消息头中会有一行：
Set-Cookie: ASPSESSIONIDCSQCRTBS=KOIPGIMBCOCBFMOBENDCAKDP; path=/
服务器通过COOKIE的方式告诉客户端你的SESSIONID是多少，在这里是“KOIPGIMBCOCBFMOBENDCAKDP”，并且服务器上保 留了和此SESSIONID相关的数据，当同一用户再次发送请求时，还会把这个COOKIE再发送回去，服务器端根据此ID找到此用户的数据，也就实现了 服务器端用户状态的保存。所以我们用ASP编程时可以使用“session("name")=user”这样的方式保存用户信息。注意此COOKIE内容 里并没有过期时间，这表示这是一个当关闭浏览器时立即过期的COOKIE，它不会被保存到硬盘上。这种工作方式比单纯用COOKIE的方式要安全很多，因 为在客户端并没有什么能让我们修改和欺骗的值，唯一的信息就是SESSIONID，而这个ID在浏览器关闭时会立即失效，除非别人能在你浏览网站期间或关闭浏览器后很短时间内知道此ID的值，才能做一些欺骗活动。因为服务器端判断SESSION过期的方式并不是断开连接或关闭浏览器，而是通过用户手工结束 SESSION或等待超时，当用户关闭浏览器后的一段时间里SESSION还没有超时，所以这时如果知道了刚才的SESSIONID，还是可以欺骗的。因 此最安全的办法还是在离开网站之前手工结束SESSION，很多网站都提供“Logout”功能，它会通过设置SESSION中的值为已退出状态或让 SESSION立即过期从而起到安全的目的。
SESSION和COOKIE的方式各有优缺点。SESSION的优点是比较安全，不容易被欺骗，缺点是过期时间短，如果用过在超过过期时间里没有向服务器发送任何信息，就会被认为超过过期了；COOKIE则相反，根据服务器端设置的超时时间，可以长时间保留信息，即使关机再开机也可能保留状态，而安全性自然大打折扣。很多网站都提供两种验证方式相结合，如果用户临时用这台电脑访问此访问则需要输入用户名和密码，不保存COOKIE；如果用户使用的是自己的个人电脑，则可以让网站在自己硬盘上保留COOKIE，以后访问时就不需要重新输入用户名和密码了。

4 POST
浏览器访问服务器常用的方式有GET和POST两种，GET方式只发送HTTP消息头，没有消息体，也就是除了要GET的基本信息之外 不向服务器提供其他信息，网页表单（FROM）的默认提交方式就是用GET方式，它会把所有向服务器提交的信息都作为URL后面的参数，如 a.asp?a=1&b=2这样的方式。而当要提交的数据量很大，或者所提交内容不希望别人直接看到时，应该使用POST方式。POST方式提交 的数据是作为HTTP消息体存在的，例如，写一个网页表单：
<form method=post>
<input type=text name=text1>
<input type=submit>
</form>
访问此网页，并在表单中填入一个“haha”，然后提交，可以看到此次提交所发送的信息如下：
POST /form.asp HTTP/1.1
Accept: */*
Referer: http://localhost:8080/form.asp
Accept-Language: zh-cn
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Content-Length: 10
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP

text1=haha
前面关键字从“GET”变为了“POST”，Content-Type变成了“application/x-www-form- urlencoded”，后面内容并无大变化，只是多了一行：Content-Length: 10，表示提交的内容的长度。空行后面是消息体，内容就是表单中所填的内容。注意此时发送的内容只是“Name=Value”的形式，表单上其他的信息不 会被发送，所以想直接从服务器端取得list box中所有的list item是办不到的，除非在提交前用一段script把所有的item内容都连在一起放到一个隐含表单域中。
如果是用表单上传文件，情况就要复杂一些了，首先是表单声明中要加上一句话：enctype='multipart/form-data'，表示这个表单将提交多段数据，并用HTML：input type=file来声明一个文件提交域。
表单内容如下：
<form method=post enctype='multipart/form-data'>
<input type=text name=text1>
<input type=file name=file1>
<input type=submit>
</form>
我们为text1输入文字：hehe，为file1选择文件haha.txt，其内容为“ABCDEFG”，然后提交此表单。提交的完全信息为：
POST /form.asp HTTP/1.1
Accept: */*
Referer: http://localhost:8080/form.asp
Accept-Language: zh-cn
Content-Type: multipart/form-data; boundary=---------------------------7d62bf2f9066c
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: localhost:8080
Content-Length: 337
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP

-----------------------------7d62bf2f9066c
Content-Disposition: form-data; name="text1"

hehe
-----------------------------7d62bf2f9066c
Content-Disposition: form-data; name="file1"; filename="H:\Documents and Settings\Administrator\桌面\haha.txt"
Content-Type: text/plain

ABCDEFG
-----------------------------7d62bf2f9066c--

显然这个提交的信息要比前述的复杂很多。Content-Type变成了“multipart/form-data”，后面还多了一个 boundary，此值是为了区分POST的内容的区段用的，只要在内容中遇到了此值，就表示下面要开始一个新的区段了，每个区段的内容相对独立。如果遇 到的是此值后面连着两个减号，则表示全部内容到此结束。每个段也分为段头和段体两部分，用空行隔开，每段都有自己的类型和相关信息。如第一区段是 text1的值，它的名称是“text1”，值为“hehe”。第二段是文件内容，段首里表明了此文件域的名称“file1”和此文件在用户磁盘上的位置，后面就是文件的内容。
如果我们想要自己写一个上传文件组件来接收HTML表单传送的文件数据，那么最核心的任务就是解析此数据包，从中取得需要的信息。

理解HTTP消息头 （四）
服务器返回的消息

服务器返回的HTTP消息也分为消息头和消息体两部分。前面连载的第二篇里已经介绍了返回消息中常见返回代码的含义。对于非正常的返回代码的处理比较简单，只要照着要求去做就好了，而对于正常的返回代码（200），其处理方式就多种多样了。

1 Content-Type

Content-Type是返回消息中非常重要的内容，它标识出这个返回内容的类型，其值为“主类型/子类型”的格式，例如最常见的就是 text/html，它的意思是说返回的内容是文本类型，这个文本又是HTML格式的。原则上浏览器会根据Content-Type来决定如何显示返回的 消息体内容。常见的内容类型有：
text/html HTML文本
image/jpeg JPG图片
image/gif GIF图片
application/xml XML文档
audio/x-mpegurl MP3文件列表，如果安装了Winamp，则可以直接把它当面M3U文件来打开
更多的内容类型可以在注册表“HKCR\MIME\Database\Content Type”下看到
对于IE6浏览器来说，如果Content-Type中的类型和实际的消息体类型不一致，那么它会根据内容中的类型来分析实际应该是什么类型，对于JPG、GIF等常用图片格式都可以正确的识别出来，而不管Content-Type中写的是什么。
如果Content-Type中指定的是浏览器可以直接打开的类型，那么浏览器就会直接打开其内容显示出来，如果是被关联到其它应用程序的类型，这时就要查找注册表中关于这种类型的注册情况，如果是允许直接打开而不需要询问的，就会直接调出这个关联的应用程序来打开这个文件，但如果是不允许直接打开的，就 会询问是否打开。对于没有关联到任何应用程序的类型，IE浏览器不知道它该如何打开，此时IE6就会把它当成XML来尝试打开。

2 Content-Disposition

如果用AddHeader的方法在HTTP消息头中加入Content-Disposition段，并指定其值为“attachment”，那么无论这个文件是何类型，浏览器都会提示我们下载此文件，因为此时它认为后面的消息体是一个“附件”，不需要由浏览器来处理了。例如，在ASP.Net中 写入如下语句：
Response.AddHeader("Content-Disposition: attachment");
请求此页面是得到的结果如：
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 23 Mar 2006 07:54:53 GMT
Content-Disposition: attachment
Cache-Control: private
Content-Type: text/html; charset=utf-8
……
也就是说，通过AddHeader函数可以为HTTP消息头加入我们自定义的内容。使用这种方法可以强制让浏览器提示下载文件，即使这个文件是我们已知的 类型，基于是HTML网页。如果想要让用户下载时提示一个默认的文件名，只需要在前面一句话后加上“filename=文件名”即可。例如：
Response.AddHeader("Content-Disposition: attachment; filename=mypage.htm");

3 Content-Type与Content-Disposition

如果把Content-Type和Content-Disposition结合在一起使用会怎么样呢？
打开一个网页时，浏览器会首先看是否有Content-Disposition: attachment这一项，如果有，无论Content-Type的值是什么，都会提示文件下载。
如果指定了filename，就会提示默认的文件名为此文件名。注意到在IE6中除了“保存”按扭外还有“打开”按扭，此时打开文件的类型是由在 filename中指定的文件扩展名决定的，例如让filename=mypic.jpg，浏览器就会查找默认的图片查看器来打开此文件。
如果没有指定filename，那么浏览器就根据Content-Type中的类型来决定文件的类型，例如Content-Type类型为 image/gif，那么就会去查找默认的看GIF图片的工具，并且设置此文件的名字为所请求的网页的主名（不带扩展名）加上对应于此文件类弄扩展名，例 如请求的mypage.aspx，就会自动变成mypage.gif。如果并没有指定Content-Type值，那么就默认它为 “text/html”，并且保存的文件名就是所请求的网页文件名。
但如果没有指定Content-Disposition，那么就和前面关于Content-Type中所讨论的情况是一样的了。

4 Cache

返回消息中的Cache用于指定网页缓存。我们经常可以看到这样的情况，打开一个网页时速度不快，但再次打开时就会快很多，原因是浏览器已经对此页面进行了缓存，那么在同一浏览器窗口中再次打开此页时不会重新从服务器端获取。网页的缓存是由HTTP消息头中的“Cache-control”来控制 的，常见的取值有private、no-cache、max-age、must-revalidate等，默认为private。其作用根据不同的重新浏 览方式分为以下几种情况：
（1） 打开新窗口
如果指定cache-control的值为private、no-cache、must-revalidate，那么打开新窗口访问时都会重新访问服务器。而如果指定了max-age值，那么在此值内的时间里就不会重新访问服务器，例如：
Cache-control: max-age=5
表示当访问此网页后的5秒内再次访问不会去服务器
（2） 在地址栏回车
如果值为private或must-revalidate（和网上说的不一样），则只有第一次访问时会访问服务器，以后就不再访问。如果值为no-cache，那么每次都会访问。如果值为max-age，则在过期之前不会重复访问。
（3） 按后退按扭
如果值为private、must-revalidate、max-age，则不会重访问，而如果为no-cache，则每次都重复访问
（4） 按刷新按扭
无论为何值，都会重复访问

当指定Cache-control值为“no-cache”时，访问此页面不会在Internet临时文章夹留下页面备份。
另外，通过指定“Expires”值也会影响到缓存。例如，指定Expires值为一个早已过去的时间，那么访问此网时若重复在地址栏按回车，那么每次都会重复访问：
Expires: Fri, 31 Dec 1999 16:00:00 GMT

在ASP中，可以通过Response对象的Expires、ExpiresAbsolute属性控制Expires值；通过Response对象的CacheControl属性控制Cache-control的值，例如：
Response.ExpiresAbsolute = #2000-1-1# ' 指定绝对的过期时间，这个时间用的是服务器当地时间，会被自动转换为GMT时间
Response.Expires = 20 ' 指定相对的过期时间，以分钟为单位，表示从当前时间起过多少分钟过期。
Response.CacheControl = "no-cache"
Expires值是可以通过在Internet临时文件夹中查看临时文件的属性看到的，如：

2、POST是被设计用来向上放东西的，而GET是被设计用来从服务器取东西的，GET也能够向服务器传送较少的数据，而Get之所以也能传送数据,只是用来设计告诉服务器,你到底需要什么样的数据.POST的信息作为HTTP 请求的内容，而GET是在HTTP 头部传输的；

3、POST与GET在HTTP 中传送的方式不同，GET的参数是在HTTP 的头部传送的，而Post的数据则是在HTTP 请求的内容里传送;

4、POST传输数据时，不需要在URL中显示出来，而GET方法要在URL中显示；

5、GET方法由于受到URL长度的限制,只能传递大约1024字节；POST传输的数据量大，可以达到2M，而根据微软方面的说法，微软对用 Request.Form() 可接收的最大数据有限制，IIS 4 中为 80 KB 字节，IIS 5 中为 100 KB 字节；

6、SOAP是依赖于HTTP POST模式实现的；

例子：

HTTP GET

发送

GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com

回复

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
  <Success>boolean</Success>
  <ErrorDescription>string</ErrorDescription>
  <ErrorNumber>int</ErrorNumber>
  <CustomerOrderReference>long</CustomerOrderReference>
  <OrderConfirmation>string</OrderConfirmation>
  <CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>

HTTP POST

发送

POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1
Host: api.efxnow.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length

UserID=string&PWD=string&OrderConfirmation=string

回复

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
  <Success>boolean</Success>
  <ErrorDescription>string</ErrorDescription>
  <ErrorNumber>int</ErrorNumber>
  <CustomerOrderReference>long</CustomerOrderReference>
  <OrderConfirmation>string</OrderConfirmation>
  <CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>

SOAP 1.2

发送

POST /DEMOWebServices2.8/Service.asmx HTTP/1.1
Host: api.efxnow.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <CancelOrder xmlns="https://api.efxnow.com/webservices2.3">
      <UserID>string</UserID>
      <PWD>string</PWD>
      <OrderConfirmation>string</OrderConfirmation>
    </CancelOrder>
  </soap12:Body>
</soap12:Envelope>

回复

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <CancelOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
      <CancelOrderResult>
        <Success>boolean</Success>
        <ErrorDescription>string</ErrorDescription>
        <ErrorNumber>int</ErrorNumber>
        <CustomerOrderReference>long</CustomerOrderReference>
        <OrderConfirmation>string</OrderConfirmation>
        <CustomerDealRef>string</CustomerDealRef>
      </CancelOrderResult>
    </CancelOrderResponse>
  </soap12:Body>
</soap12:Envelope>

1. 目的——HTTP/0.9-〉HTTP/1.0-〉HTTP/1.1

2. 要求——MUST、REQUIRED、SHOULD

3. 术语——连接(Connection)、消息(Message)、请求(Request)、应答(Response)、资源(Resource)、实体(Entity)、表示方法(Representation)、内容协商(Content Negotiation)、变量（Variant)、客户机（Client）、用户代理(User agent)、服务器(Server)、原服务器（Origin server)、代理服务器（ Proxy）、网关（gateway）、高速缓存（Cache）、可缓存（Cacheable）、直接（first-hand）、明确终止时间（explicit expiration time）、探索终止时间（heuristic expiration time）、年龄（Age）、保鲜寿命（Freshness lifetime）、保鲜（Fresh）、陈旧（Stale）、语义透明（semantically transparent）、有效性判别器（Validator）、实体标记（entity tag）或最终更改时间（Last-Modified time))、上游/下游（upstream/downstream）、向内/向外（inbound/outbound）

4. 总体操作——请求/应答、中介

二、符号惯例与一般语法（notational conversions and generic grammar）

1. 扩充BNF——name = definition,"literal",rule1 | rule2,(rule1 rule2),*rule,[rule],N rule, #rule,; comment, implied *LWS

2. 基本规则——OCTET,CHAR,UPALPHA,LOALPHA,ALPHA,DIGIT,CTL,CR,LF,SP,HT,<">

三、协议参数（protocol parameters）

1. HTTP版本——HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

2. 统一资源标示符（URI）——统一资源定位器(URL)和统一资源名称(URN)的结合，http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

3. 日期/时间格式——Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123，
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036，
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

4. 字符集——本文档中的术语"字符集"指一种用一个或更多表格将一个八字节序列转换成一个字符序列的方法，
charset=token
失踪字符集

5. 内容编码——内容编码主要用来允许文档压缩（信源编码）
content-coding= token
注册表包含下列标记：gzip，compress，deflate，identity

6. 传输编码——目的是能够确保通过网络安全传输（信道编码）
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )，
成块传输代码

7. 媒体类型——media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
规范化和原文缺省
多部分类型

8. 产品标记——product = token ["/" product-version]
product-version = token

9. 质量值——qvalue = ( "0" [ "." 0*3DIGIT ] )| ( "1" [ "." 0*3("0") ] )

10. 语言标记——language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA

11. 实体标记——entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string

12. 范围单位——range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token

四、 HTTP消息（HTTP message）

1. 消息类型——HTTP-message = Request | Response ; HTTP/1.1 messages
generic-message = start-line *(message-header CRLF) CRLF [ message-body ]
start-line = Request-Line | Status-Line

2. 消息头——HTTP头域包括常规头,请求头,应答头和实体头域
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string>

3. 消息体——message-body = entity-body| <entity-body encoded as per Transfer-Encoding>

4. 消息的长度——决定因素

5. 常规头域——general-header = Cache-Control| Connection| Date| Pragma| Transfer-Encoding

五、 请求（request）

首行包括利用资源的方式,区分资源的标识,以及协议的版本号
Request = Request-Line * (( general-header| request-header| entity-header ) CRLF) CRLF [ message-body ]

1. 请求行——Request-Line = Method SP Request-URI SP HTTP-Version CRLF
方法——方法标记指的是在请求URI所指定的资源上所实现的方式
Method = "OPTIONS"| "GET"| "POST"| "PUT"| "DELETE"| "TRACE"| "CONNECT"| extension-method
extension-method = token
请求URL——请求URL是一种全球统一的应用于资源请求的资源标识符
Request-URI = "*" | absoluteURI | abs_path | authority
请求行举例：GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

2. 请求定义的资源——一个INTERNET请求所定义的精确资源由请求URL和主机报头域所决定

3. 请求报头域——request-header = Accept| Accept-Charset| Accept-Encoding| Accept-Language| Authorization| Expect| From| Host| If-Match| If-Modified-Since| If-None-Match| If-Range| If-Unmodified-Since| Max-Forwards| Proxy-Authorization| Range| Referer| TE| User-Agent

六、 应答（response）

接收和翻译一个请求信息后，服务器发出一个HTTP应答信息
Response = Status-Line*(( general-header| response-header| entity-header ) CRLF) CRLF [ message-body ]

1. 状态行——Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状态码——状态码是试图理解和满足请求的三位数字的整数码，1xx,2xx,3xx,4xx,5xx，100-〉505-〉扩展码

2. 应答报头域——response-header = Accept-Ranges| Age| Location| Proxy-Authenticate| Retry-After| Server| Vary| WWW-Authenticate

七、 实体（entity）

在未经特别规定的情况下，请求与应答的消息也可以传送实体。 实体包括实体报头域与实体正文，而有些应答只包括实体报头。

1. 实体报头域——entity-header = Allow | Content-Encoding| Content-Language| Content-Length | Content-Location| Content-MD5| Content-Range| Content-Type| Expires| Last-Modified| extension-header
extension-header = message-header

2. 实体正文——entity-body = *OCTET
entity-body := Content-Encoding( Content-Type( data ) )

八、 连接（connection）

1. 持续连接——优点
持续连接是任何HTTP连接的缺省方式，支持持续连接的客户机可以以流水线方式发送请求
代理服务器

2. 消息传递要求——持续连接与流量控制
监视连接中出错状态的消息
100号状态的用途
服务器过早关闭连接时客户机的动作

九、 方法定义（method definitions）

1. 安全和等幂方法
安全方法——GET和HEAD方法除了补救外不应该有别的采取措施的含义
等幂方法——没有副作用的序列是等幂的

2. OPTIONS——OPTIONS方法代表在请求URI确定的请求/应答过程中通信条件是否可行的信息

3. GET——GET方法说明了重建信息的内容由请求URI来确定

4. HEAD——除了应答中禁止返回消息正文外,HEAD方法与GET方法一样

5. POST——POST方法实现的实际功能取决于服务器

6. PUT——PUT方法要求所附实体存储在提供的请求URI下

7. DELETE——DELELE方法要求原服务器释放请求URI指向的资源

8. TRACE——TRACE方法用于调用远程的应用层循环请求消息

9. CONNECT——CONNECT方法用于能动态建立起隧道的代理服务器

十、 状态码定义（status code definitions）

1. 信息1XX——
100继续
101转换协议

2. 成功2XX——
200请求成功
201创建
202接受
203非权威信息
204无内容
205重置内容
206局部内容

3. 重新定向3XX——
300多样选择
301永久移动
302创立
303观察别的部分
304只读
306(没有用的)
307临时重发

4. 客户错误4xx——
400坏请求
401未授权的
402必需的支付
403禁用
404没有找到
405不被允许的方法
406不接受
407代理服务器认证所必需
408请求超时
409冲突
410停止
411必需的长度
412预处理失败
413请求实体太大
414请求的URI过长
415不被支持的媒体类型
416请求范围不满足
417期望失败

5. 服务器错误5xx——
500服务器内部错误
501不能实现
502坏网关
503难以获得的服务
504网关超时
505 HTTP版本不支持

十一、 访问验证（access authentication）——可选择

十二、 内容谈判（content negotiation）

HTTP为了"内容谈判"提供了一些机制，即当有很多种可能的表示时如何选择对于一个请求的最佳的表示。

1. 服务器驱动谈判——一个请求的最佳表示的选择由服务器提供的运算法则来完成

2. 代理驱动谈判——对于一个应答的最佳表示法的选择是在代理从原服务器端收到最初的应答后实现的

3. 透明谈判——透明的判断是服务器驱动和代理驱动谈判的结合体

十三、 HTTP中的缓存（caching in HTTP）

HTTP典型应用于能通过采用缓存技术而提高性能的分布式信息系统

1. 缓存——
缓存正确性
警告信息
缓存控制机制
直接的用户代理警告
规则和警告的例外情况
由客户控制的行为

2. 过期模型——
服务器指定模型
启发式过期
年龄计算
过期计算
澄清过期值
澄清多重响应

3. 确认模型——当缓存器想要用一个失时效的条目来相应客户的请求,他首先必须向源服务器检验这一缓存条目是否仍然可用
最后修改日期
标签缓存确认器
强弱控制器
关于何时使用实体标签和最后修改时间的规则
不确认条件

4. 响应的缓存能力——除非被明确限制,缓存系统可以将一成功的响应作为缓存实体一直存储

5. 从缓存构造响应——
端到端和Hop-by-hop报头
不可更改报头
联合报头
联合字节范围

6. 缓存谈判响应

7. 共享与非共享缓存

8. 错误和不完全响应缓存行为

9. GET和 HEAD的副作用

10. 刷新或删除后的无效性

11. 强制写通过

12. 缓存替换

13. 历史纪录

十四、 报头域定义（header field definitions）

1. Accept——Accept = "Accept" ":" #( media-range [ accept-params ] )
media-range = ( "*/*"| ( type "/" "*" )| ( type "/" subtype )) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
例1：Accept: audio/*; q=0.2, audio/basic
例2：Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

2. Accept-Charset——Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
例：Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

3. Accept-Encoding——Accept-Encoding = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
例：Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

4. Accept-Language——Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
例：Accept-Language: da, en-gb;q=0.8, en;q=0.7

5. Accept-Range——Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
例：Accept-Ranges: bytes

6. Age——Age = "Age" ":" age-value
age-value = delta-seconds

7. Allow——Allow = "Allow" ":" #Method
例：Allow: GET, HEAD, PUT

8. Authorization——Authorization = "Authorization" ":" credentials

9. Cache-Control——Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive| cache-response-directive
cache-request-directive ="no-cache"| "no-store"| "max-age" "=" delta-seconds| "max-stale" [ "=" delta-seconds ]| "min-fresh" "=" delta-seconds| "no-transform"| "only-if-cached"| cache-extension
cache-response-directive ="public"| "private" [ "=" <"> 1#field-name <"> ]| "no-cache" [ "=" <"> 1#field-name <"> ]| "no-store"| "no-transform"| "must-revalidate"| "proxy-revalidate"| "max-age" "=" delta-seconds| "s-maxage" "=" delta-seconds| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
什么是可缓存的
哪些可能被缓存保存
对基本过期失效机制的改进
缓存重新确认有效和重载控制
不得转换的指令
缓存控制扩展

10. Connection——Connection = "Connection" ":" 1#(connection-token)
connection-token = token
例：Connection: close

11. Content-Encoding——Content-Encoding = "Content-Encoding" ":" 1#content-coding
例：Content-Encoding: gzip

12. Content-Language——Content-Language = "Content-Language" ":" 1#language-tag
例：Content-Language: mi, en

13. Content-Length——Content-Length = "Content-Length" ":" 1*DIGIT
Content-Length: 3495

14. Content-Location——Content-Location = "Content-Location" ":"( absoluteURI | relativeURI )

15. Content-MD5——Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>

16. Content-Range——Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/"( instance-length | "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | "*"
instance-length = 1*DIGIT
例：The first 500 bytes:bytes 0-499/1234

17. Content-Type——Content-Type = "Content-Type" ":" media-type
例：Content-Type: text/html; charset=ISO-8859-4

18. Date——Date = "Date" ":" HTTP-date
例：Date: Tue, 15 Nov 1994 08:12:31 GMT
没有时钟的原服务器的运作

19. Etag——ETag = "ETag" ":" entity-tag
例：ETag: W/"xyzzy"

20. Expect——Expect = "Expect" ":" 1#expectation
expectation = "100-continue" | expectation-extension
expectation-extension = token [ "=" ( token | quoted-string )*expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ]

21. Expires——Expires = "Expires" ":" HTTP-date
例：Expires: Thu, 01 Dec 1994 16:00:00 GMT

22. From——From = "From" ":" mailbox
例：From: webmaster@w3.org

23. Host——Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

24. If-Match——If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
例：If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"

25. If-Modified-Since——If-Modified-Since = "If-Modified-Since" ":" HTTP-date
例：If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

26. If-None-Match ——If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
例：If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"

27. If-Range ——If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

28. If-Unmodified-Since ——If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
例：If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

29. Last-Modified ——Last-Modified = "Last-Modified" ":" HTTP-date
例：Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

30. Location ——Location = "Location" ":" absoluteURI
Location: http://www.w3.org/pub/WWW/People.html

31. Max-Forwards ——Max-Forwards = "Max-Forwards" ":" 1*DIGIT

32. Pragma ——Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]

33. Proxy-Authenticate ——Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge

34. Proxy-Authorization ——Proxy-Authorization = "Proxy-Authorization" ":" credentials

35. Range——字节范围
范围检索请求
Range = "Range" ":" ranges-specifier

36. Referer——Referer = "Referer" ":" ( absoluteURI | relativeURI )

37. Retry-After ——Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )

38. Server ——Server = "Server" ":" 1*( product | comment )

39. TE ——TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
例：TE: trailers, deflate;q=0.5

40. Trailer ——Trailer = "Trailer" ":" 1#field-name

41. Transfer-Encoding ——Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
例：Transfer-Encoding: chunked

42. Upgrade——Upgrade = "Upgrade" ":" 1#product
例：Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

43. User-Agent ——User-Agent = "User-Agent" ":" 1*( product | comment )
例：User-Agent: CERN-LineMode/2.15 libwww/2.17b3

44. Vary ——Vary = "Vary" ":" ( "*" | 1#field-name )

45. Via ——Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
例：Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

46. Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text [SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
warn-text = quoted-string
warn-date = <"> HTTP-date <">

47. WWW-Authenticate ——WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

十五、 安全考虑（security considerations）

一些建议，但是并不包括最终解决方案

1. 个人信息
服务器日志信息的滥用
敏感信息的传输
URI中敏感信息的编码
连接到Accept报头的机要问题

2. 基于文件和路径名称的攻击

3. DNS欺骗

4. Location（位置）报头和欺骗

5. 内容倾向问题

6. 鉴定证书和空闲的客户机

7. 代理服务器和高速缓存
对代理服务器的拒绝服务攻击

十六、 感谢

十七、 参考文献

十八、 作者地址

十九、 附录

HTTP使用内容类型，是指Web服务器向Web浏览器返回的文件都有与之相关的类型。所有这些类型在MIME　Internet邮件协议上模型化，即Web服务器告诉Web浏览器该文件所具有的种类，是HTML文档、GIF格式图像、声音文件还是独立的应用程序。大多数Web浏览器都拥有一系列的可配置的辅助应用程序，它们告诉浏览器应该如何处理Web服务器发送过来的各种内容类型。

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

（1）    建立TCP连接

在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80

（2）    Web浏览器向Web服务器发送请求命令

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令

例如：GET/sample/hello.jsp HTTP/1.1

（3）    Web浏览器发送请求头信息

浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

（4）    Web服务器应答

客户机向服务器发出请求后，服务器会客户机回送应答，

HTTP/1.1 200 OK

应答的第一部分是协议的版本号和应答状态码

（5）    Web服务器发送应答头信息

正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

（6）    Web服务器向浏览器发送数据

Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

（7）    Web服务器关闭TCP连接

一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

HTTP请求格式

当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成：

l   请求方法URI协议/版本

l   请求头(Request Header)

l   请求正文

下面是一个HTTP请求的例子：

GET/sample.jspHTTP/1.1

Accept:image/gif.image/jpeg,*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)

Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

（1）       请求方法URI协议/版本

请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1

以上代码中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。

根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1支持7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet应用中，最常用的方法是GET和POST。

URL完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。

（2）　请求头(Request Header)

请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度等。

Accept:image/gif.image/jpeg.*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:localhost

User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)

Accept-Encoding:gzip,deflate.

（3）　请求正文

请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息：

username=jinqiao&password=1234

在以上的例子的HTTP请求中，请求的正文只有一行内容。当然，在实际应用中，HTTP请求正文可以包含更多的内容。

HTTP请求方法我这里只讨论GET方法与POST方法

GET方法

GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上。例如

Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB

从上面的URL请求中，很容易就可以辩认出表单提交的内容。（？之后的内容）另外由于GET方法提交的数据是作为URL请求的一部分所以提交的数据量不能太大

POST方法

POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。

从编程的角度来讲，如果用户通过GET方法提交数据，则数据存放在QUERY＿STRING环境变量中，而POST方法提交的数据则可以从标准输入流中获取。

HTTP应答与HTTP请求相似，HTTP响应也由3个部分构成，分别是：

l 　协议状态版本代码描述

l 　响应头(Response Header)

l 　响应正文

下面是一个HTTP响应的例子：

HTTP/1.1 200 OK

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:23:42 GMT

Content-Length:112

<html>
<head>

<title>HTTP响应示例<title>

</head>

<body>

Hello HTTP!

</body>

</html>

协议状态代码描述HTTP响应的第一行类似于HTTP请求的第一行，它表示通信所用的协议是HTTP1.1服务器已经成功的处理了客户端发出的请求（200表示成功）:

HTTP/1.1 200 OK
响应头(Response Header)响应头也和请求头一样包含许多有用的信息，例如服务器类型、日期时间、内容类型和长度等：

Server:Apache Tomcat/5.0.12

Date:Mon,6Oct2003 13:13:33 GMT

Content-Type:text/html

Last-Moified:Mon,6 Oct 2003 13:23:42 GMT

Content-Length:112

响应正文响应正文就是服务器返回的HTML页面：

<html>
<head>

<title>HTTP响应示例<title>

</head>

<body>

Hello HTTP!

</body>

</html>

响应头和正文之间也必须用空行分隔。　　

HTTP应答码

HTTP应答码也称为状态码，它反映了Web服务器处理HTTP请求状态。HTTP应答码由3位数字构成，其中首位数字定义了应答码的类型：

1XX－信息类(Information),表示收到Web浏览器请求，正在进一步的处理中

2XX－成功类（Successful）,表示用户请求被正确接收，理解和处理例如：200 OK

3XX-重定向类(Redirection),表示请求没有成功，客户必须采取进一步的动作。

4XX-客户端错误(Client Error)，表示客户端提交的请求有错误 例如：404 NOT  Found，意味着请求中所引用的文档不存在。

5XX-服务器错误(Server Error)表示服务器不能完成对请求的处理：如 500

对于我们Web开发人员来说掌握HTTP应答码有助于提高Web应用程序调试的效率和准确性。

安全连接

Web应用最常见的用途之一是电子商务，可以利用Web服务器端程序使人们能够网络购物，需要指出一点是，缺省情况下，通过Internet发送信息是不安全的，如果某人碰巧截获了你发给朋友的一则消息，他就能打开它，假想在里面有你的信用卡号码，这会有多么糟糕，幸运的是，很多Web服务器以及Web浏览器都有创立安全连接的能力，这样它们就可以安全的通信了。

通过Internet提供安全连接最常见的标准是安全套接层(Secure Sockets layer,SSl)协议。SSL协议是一个应用层协议(和HTTP一样)，用于安全方式在Web上交换数据，SSL使用公开密钥编码系统。从本质讲，这意味着业务中每一方都拥有一个公开的和一个私有的密钥。当一方使用另一方公开密钥进行编码时，只有拥有匹配密钥的人才能对其解码。简单来讲，公开密钥编码提供了一种用于在两方之间交换数据的安全方法，SSL连接建立之后，客户和服务器都交换公开密钥，并在进行业务联系之前进行验证，一旦双方的密钥都通过验证，就可以安全地交换数据。

下面这个例子显示了一个HTTP请求的Header内容，这些数据是真正以网络HTTP协议从IE浏览器传递到Apache服务器上的。

GET /icwork/? search=product HTTP/1.1

Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,application/vnd.ms-powerpoint,application/vnd.ms-excel,application/msword,*.*

Accept-Language:en-us

Accept-Encoding:gzip,deflate

User-Agent:Mozilla/4.0(compatible;MSIE 5.01;Windows NT 5.0;DigExt)

Host:www.icconcept.com:8080

Referer:http://www.yoursite.com/header.html

Connection:Keep-Alive

这段程序使用了6个Header，还有一些Header没有出现。我们参考这个例子具体解释HTTP请求格式。

1.HTTP请求行：请求行格式为Method Request-URI Protocol。在上面这个例子里，“GET /icwork/? search=pruduct HTTP/1.1”是请求行。

2.Accept:指浏览器或其他客户可以接爱的MIME文件格式。Servlet可以根据它判断并返回适当的文件格式。

3.Accept-Charset：指出浏览器可以接受的字符编码。英文浏览器的默认值是ISO-8859-1.

4.Accept-Language：指出浏览器可以接受的语言种类，如en或en-us，指英语。

5.Accept-Encoding：指出浏览器可以接受的编码方式。编码方式不同于文件格式，它是为了压缩文件并加速文件传递速度。浏览器在接收到Web响应之后先解码，然后再检查文件格式。

6.Authorization：当使用密码机制时用来标识浏览器。

7.Cache-Control：设置关于请求被代理服务器存储的相关选项。一般servlet用不到。

8.Connection：用来告诉服务器是否可以维持固定的HTTP连接。HTTP/1.1使用Keep-Alive为默认值，这样，当浏览器需要多个文件时(比如一个HTML文件和相关的图形文件)，不需要每次都建立连接。

9.Content-Type：用来表名request的内容类型。可以用HttpServletRequest的getContentType()方法取得。

10.Cookie：浏览器用这个属性向服务器发送Cookie。Cookie是在浏览器中寄存的小型数据体，它可以记载和服务器相关的用户信息，也可以用来实现会话功能。

11.Expect：表时客户预期的响应状态。

12.From：给出客户端HTTP请求负责人的email地址。

13.Host：对应网址URL中的Web名称和端口号。

14.If-Match：供PUT方法使用。

15.If-Modified-Since：客户使用这个属性表明它只需要在指定日期之后更改过的网页。因为浏览器可以使用其存储的文件而不必从服务器请求，这样节省了Web资源。由于Servlet是动态生成的网页，一般不需要使用这个属性。

16.If-None-Match：和If-Match相反的操作，供PUT方法使用。

17.If-Unmodified-Since：和If-Match-Since相反。

18.Pragma：这个属性只有一种值，即Pragma：no-cache,表明如果servlet充当代理服务器，即使其有已经存储的网页，也要将请求传递给目的服务器。

19.Proxy-Authorization：代理服务器使用这个属性，Servlet一般用不到。

20.Range：如果客户有部分网页，这个属性可以请求剩余部分。

21.Referer：表明产生请求的网页URL。如比从网页/icconcept/index.jsp中点击一个链接到网页/icwork/search，在向服务器发送的GET/icwork/search中的请求中，Referer是http://hostname:8080/icconcept/index.php。这个属性可以用来跟踪Web请求是从什么网站来的。

22.Upgrage：客户通过这个属性设定可以使用与HTTP/1.1不同的协议。

23.User-Agent：是客户浏览器名称。

24.Via：用来记录Web请求经过的代理服务器或Web通道。

25.Warning：用来由客户声明传递或存储(cache)错误。

SOAP=RPC+HTTP+XML

       SOAP简单的理解，就是这样的一个开放协议SOAP=RPC+HTTP+XML：采用HTTP作为底层通讯协议；RPC作为一致性的调用途径，ＸＭＬ作为数据传送的格式，允许服务提供者和服务客户经过防火墙在INTERNET进行通讯交互。RPC的描叙可能不大准确，因为SOAP一开始构思就是要实现平台与环境的无关性和独立性，每一个通过网络的远程调用都可以通过SOAP封装起来，包括DCE（Distributed Computing Environment ）　RPC CALLS，COM/DCOM CALLS, CORBA CALLS, JAVA CALLS，etc。

       SOAP 使用 HTTP 传送 XML，尽管HTTP 不是有效率的通讯协议，而且 XML 还需要额外的文件解析（parse），两者使得交易的速度大大低于其它方案。但是XML 是一个开放、健全、有语义的讯息机制，而 HTTP 是一个广泛又能避免许多关于防火墙的问题，从而使SOAP得到了广泛的应用。但是如果效率对你来说很重要，那么你应该多考虑其它的方式，而不要用 SOAP。