HTTP协议基础培训教程.docx

HTTP协议基础培训教程.docx

《HTTP协议基础培训教程.docx》由会员分享，可在线阅读，更多相关《HTTP协议基础培训教程.docx（19页珍藏版）》请在冰豆网上搜索。

HTTP协议基础培训教程

HTTP协议基础培训教程

协议基础

　由两部分组成：

要求和响应。

当你在Web扫瞄器中输入一个URL时，扫瞄器将依照你的要求创建并发送要求，该要求包含所输入的URL以及一些与扫瞄器本身相关的信息。

当服务器收到那个要求时将返回一个响应，该响应包括与该要求相关的信息以及位于指定URL〔假如有的话〕的数据。

直到扫瞄器解析该响应并显示出网页〔或其他资源〕为止。

　　要求

　　要求的格式如下所示：

[]

GET/runwit/helloworld/1.1

Host:

User-Agent:

Mozilla/5.0（Windows;U;WindowsNT5.1;en-US;rv:

1.7.6）

Gecko/20050225Firefox/1.0.1

Connection:

Keep-Alive

　　要求行的第一部分说明了该要求是GET要求。

该行的第二部分是一个斜杠〔/〕，用来说明要求的是该域名的根名目。

该行的最后一部分说明使用的是1.1版本〔另一个可选项是1.0〕。

那么要求发到哪里去呢？

这确实是第二行的内容。

　　第2行是要求的第一个首部，HOST。

首部HOST将指出要求的目的地。

结合HOST和上一行中的斜杠〔/〕，能够通知服务器要求的是/〔1.1才需要使用首部HOST，而原先的1.0版本那么不需要使用〕。

第三行中包含的是首部User-Agent，服务器端和客户端脚本都能够访问它，它是扫瞄器类型检测逻辑的重要基础。

该信息由你使用的扫瞄器来定义〔在本例中是Firefox1.0.1〕，同时在每个要求中将自动发送。

最后一行是首部Connection，通常将扫瞄器操作设置为Keep-Alive〔因此也能够设置为其他值，但这差不多超出了本书讨论的范畴〕。

注意，在最后一个首部之后有一个空行。

即使不存在要求主体，那个空行也是必需的。

　　假如要猎取一个诸如s的m域内的页面，那么该要求可能类似于：

GET/books//1.1

Host:

User-Agent:

Mozilla/5.0（Windows;U;WindowsNT5.1;en-US;rv:

1.7.6）

Gecko/20050225Firefox/1.0.1

Connection:

Keep-Alive

　　注意只有第一行的内容发生了变化，它只包含URL中m后面的部分。

　　要发送GET要求的参数，那么必须将这些额外的信息附在URL本身的后面。

其格式类似于：

URL?

name1=value1&name2=value2&..&nameN=valueN

　　该信息称之为查询字符串〔querystring〕，它将会复制在要求的要求行中，如下所示：

GET/books/?

name=Professional%20Ajax/1.1

Host:

User-Agent:

Mozilla/5.0（Windows;U;WindowsNT5.1;en-US;rv:

1.7.6）

Gecko/20050225Firefox/1.0.1

Connection:

Keep-Alive

　　注意，为了将文本〝ProfessionalAjax〞作为URL的参数，需要编码处理其内容，将空格替换成%20，这称为URL编码〔URLencoding〕，常用于的许多地点〔JavaScript提供了内建的函数来处理URL编码和解码，这些将在本章中的后续部分中说明〕。

〝名称—值〞〔name—value〕对用&隔开。

绝大部分的服务器端技术能够自动对要求主体进行解码，并为这些值的访问提供一些逻辑方式。

因此，如何使用这些数据依旧由服务器决定的。

　　扫瞄器发送的首部，通常比本文中所讨论的要多得多。

为了简单起见，那个地点的例子尽可能简短。

　　另一方面，POST要求在要求主体中为服务器提供了一些附加的信息。

通常，当填写一个在线表单并提交它时，这些填入的数据将以POST要求的方式发送给服务器。

　　以下确实是一个典型的POST要求：

POST/runwit/helloword.jsp//1.1

Host:

User-Agent:

Mozilla/5.0（Windows;U;WindowsNT5.1;en-US;rv:

1.7.6）

Gecko/20050225Firefox/1.0.1

Content-Type:

application/x-

Content-Length:

40

Connection:

Keep-Alive

name=Professional%20Ajax&publisher=Wiley

　　从上面能够发觉，POST要求和GET要求之间有一些区别。

第一，要求行开始处的GET改为了POST，以表示不同的要求类型。

你会发觉首部Host和User-Agent仍旧存在，在后面有两个新行。

其中首部Content-Type说明了要求主体的内容是如何编码的。

扫瞄器始终以application/x-urlencoded的格式编码来传送数据，这是针对简单URL编码的MIME类型。

首部Content-Length说明了要求主体的字节数。

在首部Connection后是一个空行，再后面确实是要求主体。

与大多数扫瞄器的POST要求一样，这是以简单的〝名称—值〞对的形式给出的，其中name是ProfessionalAjax，publisher是Wiley。

你能够以同样的格式来组织URL的查询字符串参数。

　　正如前面所提到的，还有其他的要求类型，它们遵从的差不多格式与GET要求和POST要求相同。

下一步我们来看看服务器将对要求发送什么响应。

　　响应

　　如下所示，响应的格式与要求的格式十分类似：

[]

　　正如你所见，在响应中唯独真正的区别在于第一行中用状态信息代替了要求信息。

状态行〔statusline〕通过提供一个状态码来说明所要求的资源情形。

以下确实是一个响应的例子：

/1.1200OK

Date:

Sat,31Dec200523:

59:

59GMT

Content-Type:

text/html;charset=ISO-8859-1

Content-Length:

122

--bodygoeshere-->

　　在本例中，状态行给出的状态代码是200，以及消息OK。

状态行始终包含的是状态码和相应的简短消息，以幸免纷乱。

最常用的状态码有：

　　◆200（OK）:

找到了该资源，同时一切正常。

　　◆304（NOTMODIFIED）:

该资源在上次要求之后没有任何修改。

这通常用于扫瞄器的缓存机制。

　　◆401（UNAUTHORIZED）:

客户端无权访问该资源。

这通常会使得扫瞄器要求用户输入用户名和密码，以登录到服务器。

　　◆403（FORBIDDEN）:

客户端未能获得授权。

这通常是在401之后输入了不正确的用户名或密码。

　　◆404（NOTFOUND）:

在指定的位置不存在所申请的资源。

　　◆500:

服务器内部错误。

　　在状态行之后是一些首部。

通常，服务器会返回一个名为Data的首部，用来说明响应生成的日期和时刻〔服务器通常还会返回一些关于其自身的信息，尽管并非是必需的〕。

接下来的两个首部大伙儿应该熟悉，确实是与POST要求中一样的Content-Type和Content-Length。

在本例中，首部Content-Type指定了MIME类型HTML〔text/html〕，其编码类型是ISO-8859-1〔这是针对美国英语资源的编码标准〕。

响应主体所包含的确实是所要求资源的HTML源文件〔尽管还可能包含纯文本或其他资源类型的二进制数据〕。

扫瞄器将把这些数据显示给用户。

　　注意，那个地点并没有指明针对该响应的要求类型，只是这关于服务器并不重要。

客户端明白每种类型的要求将返回什么类型的数据，并决定如何使用这些数据。

是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。

它于1990年提出，通过几年的使用与进展，得到不断地完善和扩展。

目前在WWW中使用的是/1.0的第六版，/1.1的规范化工作正在进行之中，而且-NG（NextGenerationof）的建议差不多提出。

协议的要紧特点可概括如下：

1.支持客户/服务器模式。

2.简单快速：

客户向服务器要求服务时，只需传送要求方法和路径。

要求方法常用的有GET、HEAD、POST。

每种方法规定了客户与服务器联系的类型不同。

由于协议简单，使得服务器的程序规模小，因而通信速度专门快。

3.灵活：

承诺传输任意类型的数据对象。

正在传输的类型由Content-Type加以标记。

4.无连接：

无连接的含义是限制每次连接只处理一个要求。

服务器处理完客户的要求，并收到客户的应答后，即断开连接。

采纳这种方式能够节约传输时刻。

5.无状态：

协议是无状态协议。

无状态是指协议关于事务处理没有经历能力。

缺少状态意味着假如后续处理需要前面的信息，那么它必须重传，如此可能导致每次连接传送的数据量增大。

另一方面，在服务器不需要先前信息时它的应答就较快。

一、协议详解之URL篇

   〔超文本传输协议〕是一个基于要求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，1.1版本中给出一种连续连接的机制，绝大多数的Web开发，差不多上构建在协议之上的Web应用。

URL（URL是一种专门类型的URI，包含了用于查找某个资源的足够的信息）的格式如下：

[":

"port][abs_path]

表示要通过协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空那么使用缺省端口80；abs_path指定要求资源的URI；假如URL中没有给出abs_path，那么当它作为要求URI时，必须以〝/〞的形式给出，通常那个工作扫瞄器自动帮我们完成。

eg:

1、输入：

扫瞄器自动转换成：

2、:

192.168.0.116:

8080/index.jsp

二、协议详解之要求篇

   要求由三部分组成，分别是：

要求行、消息报头、要求正文

1、要求行以一个方法符号开头，以空格分开，后面跟着要求的URI和协议的版本，格式如下：

MethodRequest-URI-VersionCRLF

其中Method表示要求方法；Request-URI是一个统一资源标识符；-Version表示要求的协议版本；CRLF表示回车和换行〔除了作为结尾的CRLF外，不承诺显现单独的CR或LF字符〕。

要求方法〔所有方法全为大写〕有多种，各个方法的说明如下：

GET    要求猎取Request-URI所标识的资源

POST   在Request-URI所标识的资源后附加新的数据

HEAD   要求猎取由Request-URI所标识的资源的响应消息报头

PUT    要求服务器储备一个资源，并用Request-URI作为其标识

DELETE要求服务器删除Request-URI所标识的资源

TRACE  要求服务器回送收到的要求信息，要紧用于测试或诊断

CONNECT保留今后使用

OPTIONS要求查询服务器的性能，或者查询与资源相关的选项和需求

应用举例：

GET方法：

在扫瞄器的地址栏中输入网址的方式访问网页时，扫瞄器采纳GET方法向服务器猎取资源，eg:

GET/form.html/1.1（CRLF）

POST方法要求被要求服务器同意附在要求后面的数据，常用于提交表单。

eg：

POST/reg.jsp/（CRLF）

Accept:

image/gif,image/x-xbit,...（CRLF）

...

HOST:

（CRLF）

Content-Length:

22（CRLF）

Connection:

Keep-Alive（CRLF）

Cache-Control:

no-cache（CRLF）

（CRLF）        //该CRLF表示消息报头差不多终止，在此之前为消息报头

user=jeffrey&pwd=1234//此行以下为提交的数据

HEAD方法与GET方法几乎是一样的，关于HEAD要求的回应部分来说，它的头部中包含的信息与通过GET要求所得到的信息是相同的。

利用那个方法，不必传输整个资源内容，就能够得到Request-URI所标识的资源的信息。

该方法常用于测试超链接的有效性，是否能够访问，以及最近是否更新。

2、要求报头后述

3、要求正文（略）

三、协议详解之响应篇

   在接收和说明要求消息后，服务器返回一个响应消息。

响应也是由三个部分组成，分别是：

状态行、消息报头、响应正文

1、状态行格式如下：

-VersionStatus-CodeReason-PhraseCRLF

其中，-Version表示服务器协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：

指示信息--表示要求已接收，连续处理

2xx：

成功--表示要求已被成功接收、明白得、同意

3xx：

重定向--要完成要求必须进行更进一步的操作

4xx：

客户端错误--要求有语法错误或要求无法实现

5xx：

服务器端错误--服务器未能实现合法的要求

常见状态代码、状态描述、说明：

200OK     //客户端要求成功

400BadRequest//客户端要求有语法错误，不能被服务器所明白得

401Unauthorized//要求XX，那个状态代码必须和报头域一起使用

403Forbidden//服务器收到要求，然而拒绝提供服务

404NotFound//要求资源不存在，eg：

输入了错误的URL

500InternalServerError//服务器发生不可预期的错误

503ServerUnavailable//服务器当前不能处理客户端的要求，一段时刻后可能复原正常

eg：

/1.1200OK〔CRLF〕

2、响应报头后述

3、响应正文确实是服务器返回的资源的内容

四、协议详解之消息报头篇

   消息由客户端到服务器的要求和服务器到客户端的响应组成。

要求消息和响应消息差不多上由开始行〔关于要求消息，开始行确实是要求行，关于响应消息，开始行确实是状态行〕，消息报头〔可选〕，空行〔只有CRLF的行〕，消息正文〔可选〕组成。

消息报头包括一般报头、要求报头、响应报头、实体报头。

每一个报头域差不多上由名字+〝：

〞+空格+值组成，消息报头域的名字是大小写无关的。

1、一般报头

在一般报头中，有少数报头域用于所有的要求和响应消息，但并不用于被传输的实体，只用于传输的消息。

eg：

Cache-Control  用于指定缓存指令，缓存指令是单向的〔响应中显现的缓存指令在要求中未必会显现〕，且是独立的〔一个消息的缓存指令可不能阻碍另一个消息处理的缓存机制〕，1.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主机和端口号，它通常从URL中提取出来的，eg：

我们在扫瞄器中输入：

扫瞄器发送的要求消息中，就会包含Host要求报头域，如下：

Host：

此处使用缺省端口号80，假设指定了端口号，那么变成：

Host：

:

指定端口号

User-Agent

我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的扫瞄器的名称和版本，这往往让专门多人感到专门奇异，实际上，服务器应用程序确实是从User-Agent那个要求报头域中猎取到这些信息。

User-Agent要求报头域承诺客户端将它的操作系统、扫瞄器和其它属性告诉服务器。

只是，那个报头域不是必需的，假如我们自己编写一个扫瞄器，不使用User-Agent要求报头域，那么服务器端就无法得知我们的信息了。

要求报头举例：

GET/form.html/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,05Jan200711:

21:

25GMT（CRLF）

If-None-Match:

W/"80b1a4c018f3c41:

8317"（CRLF）

User-Agent:

Mozilla/4.0（compatible;MSIE6.0;WindowsNT5.0）（CRLF）

Host:

（CRLF）

Connection:

Keep-Alive（CRLF）

（CRLF）

3、响应报头

响应报头承诺服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。

常用的响应报头

Location

Location响应报头域用于重定向同意者到一个新的位置。

Location响应报头域常用在更换域名的时候。

Server

Server响应报头域包含了服务器用来处理要求的软件信息。

与User-Agent要求报头域是相对应的。

下面是

Server响应报头域的一个例子：

Server：

Apache-Coyote/1.1

响应报头域必须被包含在401〔未授权的〕响应消息中，客户端收到401响应消息时候，并发送Authorization报头域要求服务器对其进行验证时，服务端响应报头就包含该报头域。

eg：

realm="BasicAuthTest!

"//能够看出服务器对要求资源采纳的是差不多验证机制。

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实体报头域用于指示资源的最后修改日期和时刻。

Expi