rtsp简介(ZT) && HTTP 请求报头详解(ZT)

介绍了RTSP与HTTP协议的报头格式及其区别

rtsp简介(ZT) && HTTP 请求报头详解(ZT)

Real Time Streaming Protocol或者RTSP（实时流媒体协议），是由Real network 和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP提供一种可扩展的框架，使能够提供能控制的，按需传输实时数据，比如音频和视频文件。源数据可以包括现场数据的反馈和存贮的文件。rtsp对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，

rtsp作用相当于流媒体服务器的远程控制。传输数据可以通过传输层的tcp，udp协议，rtsp也提供了基于rtp传输机制的一些有效的方法。

RTSP消息格式:

RTSP的消息有两大类,一是请求消息(request),一是回应消息(response),两种消息的格式不同.

请求消息:

方法 URI RTSP版本 CR LF

消息头 CR LF CR LF

消息体 CR LF

其中方法包括OPTION回应中所有的命令,URI是接受方的地址,例如:rtsp://192.168.20.136

RTSP版本一般都是 RTSP/1.0.每行后面的CR LF表示回车换行，需要接受端有相应的解析，最后一个消息头需要有两个CR LF

回应消息:

RTSP版本 状态码 解释 CR LF

消息头 CR LF CR LF

消息体 CR LF

其中RTSP版本一般都是RTSP/1.0,状态码是一个数值,200表示成功,解释是与状态码对应的文本解释.

简单的rtsp交互过程:

C表示rtsp客户端,S表示rtsp服务端

1.C->S:OPTION request //询问S有哪些方法可用

1.S->C:OPTION response //S回应信息中包括提供的所有可用方法

2.C->S:DESCRIBE request //要求得到S提供的媒体初始化描述信息

2.S->C:DESCRIBE response //S回应媒体初始化描述信息，主要是sdp

3.C->S:SETUP request //设置会话的属性，以及传输模式，提醒S建立会话

3.S->C:SETUP response //S建立会话，返回会话标识符，以及会话相关信息

4.C->S:PLAY request //C请求播放

介绍了RTSP与HTTP协议的报头格式及其区别

S->C:发送流媒体数据

5.C->S:TEARDOWN request //C请求关闭会话

5.S->C:TEARDOWN response //S回应该请求

上述的过程是标准的、友好的rtsp流程，但实际的需求中并不一定按部就班来。

其中第3和4步是必需的！第一步，只要服务器客户端约定好，有哪些方法可用，则option请求可以不要。第二步，如果我们有其他途径得到媒体初始化描述信息（比如http请求等等），则

我们也不需要通过rtsp中的describe请求来完成。第五步，可以根据系统需求的设计来决定是否需要。

rtsp中常用方法:

1.OPTION

目的是得到服务器提供的可用方法:

OPTIONS rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 1 //每个消息都有序号来标记，第一个包通常是option请求消息

User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器的回应信息包括提供的一些方法,例如:

RTSP/1.0 200 OK

Server: UServer 0.9.7_rc1

Cseq: 1 //每个回应消息的cseq数值和请求消息的cseq相对应

Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, SCALE, GET_PARAMETER //服务器提供的可用的方法

2.DESCRIBE

C向S发起DESCRIBE请求,为了得到会话描述信息(SDP):

DESCRIBE rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 2

token:

Accept: application/sdp

User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应一些对此会话的描述信息(sdp):

介绍了RTSP与HTTP协议的报头格式及其区别

Server: UServer 0.9.7_rc1

Cseq: 2

x-prev-url: rtsp://192.168.20.136:5000

x-next-url: rtsp://192.168.20.136:5000

x-Accept-Retransmit: our-retransmit

x-Accept-Dynamic-Rate: 1

Cache-Control: must-revalidate

Last-Modified: Fri, 10 Nov 2006 12:34:38 GMT

Date: Fri, 10 Nov 2006 12:34:38 GMT

Expires: Fri, 10 Nov 2006 12:34:38 GMT

Content-Base: rtsp://192.168.20.136:5000/xxx666/

Content-Length: 344

Content-Type: application/sdp

v=0 //以下都是sdp信息

o=OnewaveUServerNG 1451516402 1025358037 IN IP4 192.168.20.136

s=/xxx666

u=http:///

e=admin@

c=IN IP4 0.0.0.0

t=0 0

a=isma-compliance:1,1.0,1

a=range:npt=0-

m=video 0 RTP/AVP 96 //m表示媒体描述，下面是对会话中视频通道的媒体描述

a=rtpmap:96 MP4V-ES/90000

a=fmtp:96 profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307

a=control:trackID=0//trackID＝0表示视频流用的是通道0

介绍了RTSP与HTTP协议的报头格式及其区别

客户端提醒服务器建立会话,并确定传输模式:

SETUP rtsp://192.168.20.136:5000/xxx666/trackID=0 RTSP/1.0

CSeq: 3

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

//uri中带有trackID＝0，表示对该通道进行设置。Transport参数设置了传输模式，包的结构。接下来的数据包头部第二个字节位置就是interleaved，它的值是每个通道都不同的，trackID＝0

的interleaved值有两个0或1，0表示rtp包，1表示rtcp包，接受端根据interleaved的值来区别是哪种数据包。

服务器回应信息:

RTSP/1.0 200 OK

Server: UServer 0.9.7_rc1

Cseq: 3

Session: 6310936469860791894 //服务器回应的会话标识符

Cache-Control: no-cache

Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6B8B4567

4.PLAY

客户端发送播放请求:

PLAY rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 4

Session: 6310936469860791894

Range: npt=0.000- //设置播放时间的范围

User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应信息:

RTSP/1.0 200 OK

Server: UServer 0.9.7_rc1

Cseq: 4

Session: 6310936469860791894

Range: npt=0.000000-

RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309

介绍了RTSP与HTTP协议的报头格式及其区别

客户端发起关闭请求:

TEARDOWN rtsp://192.168.20.136:5000/xxx666 RTSP/1.0

CSeq: 5

Session: 6310936469860791894

User-Agent: VLC media player (LIVE555 Streaming Media v2005.11.10)

服务器回应:

RTSP/1.0 200 OK

Server: UServer 0.9.7_rc1

Cseq: 5

Session: 6310936469860791894

Connection: Close

以上方法都是交互过程中最为常用的,其它还有一些重要的方法如get/set_parameter,pause,redirect等等

ps:

sdp的格式

v=<version>

o=<username> <session id> <version> <network type> <address type> <address>

s=<session name>

i=<session description>

u=<URI>

e=<email address>

p=<phone number>

c=<network type> <address type> <connection address>

b=<modifier>:<bandwidth-value>

t=<start time> <stop time>

r=<repeat interval> <active duration> <list of offsets from start-time>

z=<adjustment time> <offset> <adjustment time> <offset> ....

k=<method>

介绍了RTSP与HTTP协议的报头格式及其区别

a=<attribute>:<value>

m=<media> <port> <transport> <fmt list>

v = （协议版本）

o = （所有者/创建者和会话标识符）

s = （会话名称）

i = * （会话信息）

u = * （URI 描述）

e = * （Email 地址）

p = * （电话号码）

c = * （连接信息）

b = * （带宽信息）

z = * （时间区域调整）

k = * （加密密钥）

a = * （0 个或多个会话属性行）

时间描述：

t = （会话活动时间）

r = * （0或多次重复次数）

媒体描述：

m = （媒体名称和传输地址）

i = * （媒体标题）

c = * （连接信息 — 如果包含在会话层则该字段可选）

b = * （带宽信息）

k = * （加密密钥）

a = * （0 个或多个媒体属性行）

参考文章：rfc2326（rtsp）；rfc2327（sdp）

HTTP 请求报头详解

介绍了RTSP与HTTP协议的报头格式及其区别

general-header ;

request-header ;

response-header ;

entity-header .

*******************************************************************************

General Header Fields

=============================

general header是request、response都可用的, 但是不能用于entity.

－－ Cache-Control

－－ Connection

－－ Date

－－ Pragma

－－ Trailer

－－ Transfer-Encoding

－－ Upgrade

－－ Via

－－ Warning

*******************************************************************************

Request Header Fields

======================

request-header fields 允许客户端传递关于request和客户端的附加信息到服务端，

－－ Accept

介绍了RTSP与HTTP协议的报头格式及其区别

－－ 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 Header Fields

===============================

response-header fields 允许服务端传递关于response的、不能放到Status-Line的附加信息。

这些头给出关于服务端的信息。

－－ Accept-Ranges

－－ Age

－－ ETag

－－ Location

介绍了RTSP与HTTP协议的报头格式及其区别

－－ Retry-After

－－ Server

－－ Vary

－－ WWW-Authenticate

*******************************************************************************

Entity Header Fields

========================

Entity-header fields 定义关于entity-body的metainformation(标题字段数据),

如果当前没有body, 则定义被request确定的资源信息.

一些metainformation是可选的; 一些是必须的。

－－ Allow

－－ Content-Encoding

－－ Content-Language

－－ Content-Length

－－ Content-Location

－－ Content-MD5

－－ Content-Range

－－ Content-Type

－－ Expires

－－ Last-Modified

－－ extension-header

一、基础篇

HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协

议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。

介绍了RTSP与HTTP协议的报头格式及其区别

的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多

行，在每行开始处，使用至少一个空格或制表符。

1、通用头域

通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩

展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。

Cache-Control头域

Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括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。各个消息

中的指令含义如下：

Public指示响应可被任何缓存区缓存。

Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。

no-cache指示请求或响应消息不能缓存

no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。

max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。

min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。

max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。

Date头域

Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。

Pragma头域

Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache-Control:no-cache相同。

2、请求消息

请求消息的第一行为下面的格式：

Method SP Request-URI SP HTTP-Version CRLF

Method表示对于Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息，只是可以在响应时，不返回消息体。POST方法可

以请求服务器接收包含在请求中的实体信息，可以用于提交表单，向新闻组、BBS、邮件群组和数据库发送消息。

SP表示空格。

介绍了RTSP与HTTP协议的报头格式及其区别

HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。

CRLF表示换行回车符。

请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展

要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。

典型的请求消息：

GEThttp://class/download.microtool.de:80/somedata.exe

Host:download.microtool.de

Accept:*/*

Pragma:no-cache

Cache-Control:no-cache

Referer:http://class/download.microtool.de/

User-Agent:Mozilla/4.04[en](Win95;I;Nav)

Range:bytes=554554-

上例第一行表示HTTP客户端（可能是浏览器、下载程序）通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息，绿色的部分表示通用头部分。

Host头域

Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。

Referer头域

Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没

有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。

Range头域

Range头域可以请求实体的一个或者多个子范围。例如，

表示头500个字节：bytes=0-499

表示第二个500字节：bytes=500-999

表示最后500个字节：bytes=-500

表示500字节以后的范围：bytes=500-

第一个和最后一个字节：bytes=0-0,-1

同时指定几个范围：bytes=500-600,601-999

但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（PartialContent）返回而不是以200（OK）。

介绍了RTSP与HTTP协议的报头格式及其区别

User-Agent头域的内容包含发出请求的用户信息。

3、响应消息

响应消息的第一行为下面的格式：

HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP-Version表示支持的HTTP版本，例如为HTTP/1.1。

Status-Code是一个三个数字的结果代码。

Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自动识别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别，后两

个数字没有分类的作用。第一个数字可能取5个不同的值：

1xx:信息响应类，表示接收到请求并且继续处理

2xx:处理成功响应类，表示动作被成功接收、理解和接受

3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理

4xx:客户端错误，客户请求包含语法错误或者是不能正确执行

5xx:服务端错误，服务器不能正确执行一个正确的请求

响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、 Location、Proxy-Authenticate、Public、Retry-After、

Server、Vary、Warning、WWW- Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一般将会作为实体头域处理。

典型的响应消息：

HTTP/1.0200OK

Date:Mon,31Dec200104:25:57GMT

Server:Apache/1.3.14(Unix)

Content-type:text/html

Last-modified:Tue,17Apr200106:46:28GMT

Etag:"a030f020ac7c01:1e9f"

Content-length:39725426

Content-range:bytes554554-40279979/40279980

上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体头域的信息。

Location响应头

Location响应头用于重定向接收者到一个新URI地址。

Server响应头

介绍了RTSP与HTTP协议的报头格式及其区别

4、实体信息

请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括Allow、Content-Base、Content-Encoding、Content-Language、 Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流，它的编码方式由Content-Encoding或Content-Type定义，它的长度由Content-Length或Content-Range定义。

Content-Type实体头

Content-Type 实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型Content-Range实体头

Content-Range实体头

用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：

Content-Range:bytes-unit SP first-byte-pos - last-byte-pos/entity-legth

例如，传送头500个字节次字段的形式：Content-Range:bytes0-499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的

范围，Content-Length表示实际传送的字节数。

Last-modified实体头

Last-modified实体头指定服务器上保存内容的最后修订时间。

5、 HTTP 头参考（microsoft）

HTTP 请求和 HTTP 响应都使用头发送有关 HTTP 消息的信息。头由一系列行组成，每行都包含名称，然后依次是冒号、空格、值。字段可按任何顺序排列。某些头字段既能用于请求头也

能用于响应头，而另一些头字段只能用于其中之一。

许多请求头字段都允许客户端在值部分指定多个可接受的选项，有时甚至可以对这些选项的首选项进行排名。多个项以逗号分隔。例如，客户端可以发送包含 “Content-Encoding: gzip,

compress,”的请求头，表示可以接受各种压缩类型。如果服务器的响应正文使用 gzip 编码，其响应头中将包含“Content-Encoding: gzip”。

有些字段可以在单个头中出现多次。例如，头可以有多个“Warning”字段。

下表列出了 HTTP 1.1 头字段。注意：有些头字段是 MIME 字段。MIME 字段在 Internet Engineering Task Force (IETF) 文档 RFC 2045 中进行了定义，但也可用于 HTTP 1.1 协议。有

关 MIME 和 HTTP 1.1 规范的详细信息，请参阅 IEIF 页。

一般头字段

一般头字段可用于请求消息和响应消息。

名称 示例值

Cache-Control "max-age=10"

Connection "close"

Date "Tue, 11 Jul 2000 18:23:51 GMT"

Pragma "no-cache"

介绍了RTSP与HTTP协议的报头格式及其区别

Transfer-Encoding "chunked"

Upgrade "SHTTP/1.3"

Via "HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"

Warning "112 Disconnected Operation"

请求头字段

请求头字段仅用于请求消息。

名称 示例值

Accept "text/html, image/*"

Accept-Charset "iso8859-5"

Accept-Encoding "gzip, compress"

Accept-Language "en, fr"

Authorization [credentials]

Content-Encoding "gzip"

Expect "100-continue"

From ""

Host ""

If-Match "entity_tag001"

If-Modified-Since "Tue, 11 Jul 2000 18:23:51 GMT"

If-None-Match "entity_tag001"

If-Range "entity_tag001" or "Tue, 11 Jul 2000 18:23:51 GMT"

If-Unmodified-Since "Tue, 11 Jul 2000 18:23:51 GMT"

Max-Forwards "3"

Proxy-Authorization [credentials]

Range "bytes=100-599"

Referer ""

TE "trailers"

User-Agent "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"

>>请求头字段的具体含义

介绍了RTSP与HTTP协议的报头格式及其区别

Accept-Charset：浏览器可接受的字符集。

Accept-Encoding：浏览器能够进行解码的数据编码方式，比如gzip。

Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。

Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。

Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面

包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点， Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入

ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。

Content-Length：表示请求消息正文的长度。

Cookie：设置cookie,这是最重要的请求头信息之一

From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。

Host：初始URL中的主机和端口。

If-Modified-Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。

Pragma：指定“no-cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。

Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。

User-Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。

UA-Pixels，UA-Color，UA-OS，UA-CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。

响应头字段

响应头字段仅用于响应消息。

名称 示例值

Accept-Ranges "none"

Age "2147483648(2^31)"

ETag "b38b9-17dd-367c5dcd"

Last-Modified "Tue, 11 Jul 2000 18:23:51 GMT"

Location ""

Proxy-Authenticate [challenge]

Retry-After "Tue, 11 Jul 2000 18:23:51 GMT" or "60"

Server "Microsoft-IIS/5.0"

Vary "Date"

WWW-Authenticate [challenge]

介绍了RTSP与HTTP协议的报头格式及其区别

实体头字段可以用于请求消息或响应消息。实体头字段中包含消息实体正文的有关信息，如使用的编码格式。

名称 示例值

Allow "GET, HEAD"

Content-Encoding "gzip"

Content-Language "en"

Content-Length "8445"

Content-Location "http://localhost/page.asp"

Content-MD5 [md5-digest]

Content-Range "bytes 2543-4532/7898"

Content-Type "text/html"

Expires "Tue, 11 Jul 2000 18:23:51 GMT"

Last-Modified "Tue, 11 Jul 2000 18:23:51 GMT"

>>实体头字段的具体含义

Allow 服务器支持哪些请求方法（如GET、POST等）。

Content-Encoding 文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的

GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。

Content-Length 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。

Content-Type 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。

Date 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。

Expires 应该在什么时候认为文档已经过期，从而不再缓存它？

Last-Modified 文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304

（Not Modified）状态。

Location 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。

Refresh 表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。

注意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV="Refresh" C＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的HTML编写者十分重要。

但是，对于Servlet来说，直接设置 Refresh头更加方便。

注意Refresh的意义是“N秒之后刷新本页面或访问指定页面”，而不是“每隔N秒刷新本页面或访问指定页面 ”。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则可以

阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV="Refresh" ...＞。

注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。