亚洲精品在线电影,极品视频在线,欧美亚洲综合网

j2me 联网技术分析�ȝ��

LukeW — Tue, 04 Nov 2008 08:22:00 GMT

基本�?

Generic Connections

In the CLDC Generic Connection framework, all connections are created using the open static method from the Connector class. If successful, this method returns an object that implements one of the generic connection interfaces. Figure 1 shows how these interfaces form an is-a hierarchy. The Connection interface is the base interface such that StreamConnectionNotifier is a Connection and InputConnection is a Connection too.

Figure 1: Connection interface hierarchy

The Connection interface is the most basic connection type. It can only be opened and closed.
The InputConnection interface represents a device from which data can be read. Its openInputStream method returns an input stream for the connection.
The OuputConnection interface represents a device to which data can be written. Its openOutputStream method returns an output stream for the connection.
The StreamConnection interface combines the input and output connections.
The ContentConnection is a subinterface of StreamConnection. It provides access to some of the basic meta data information provided by HTTP connections.
The StreamConnectionNotified waits for a connection to be established. It returns a StreamConnection on which a communication link has ben established.
The DatagramConnection represents a datagram endpoint.

The open method of the Connector class has the following syntax, where the String parameter has the format "protocol:address;parameters".

Connector.open(String);

Here are a few examples:

HTTP Connection

Connector.open("http://java.sun.com/developer");

Datagram Connection

Connector.open("datagram://address:port#");

Communicate with a Port

Connector.open("comm:0;baudrate=9600');

Open Files

Connector.open("file:/myFile.txt");

The HttpConnection Interface:

The HTTP protocol is a request-response application protocol in which the parameters of the request must be set before the request is sent. The connection could be in one of the three following states:

Setup: No connection yet
Connected: Connection has been made, the request has been sent, and some response is expected
Closed: Connection is closed

In the setup state the following methods can be invoked:

setRequestMethod
setRequestProperty

For example, suppose you have this connection:

HttpConnection c = (HttpConnection)
Connector.open("http://java.sun.com/developer");

Then, you can set the request method to be of type POST as follows:

c.setRequestMethod(HttpConnection.POST);

And likewise, you can set some of the HTTP properties. For example, you can set the User-Agent as follows:

c.setRequestProperty("User-Agent","Profile/MIDP-1.0 Configuration/CLDC-1.0");

If there is a method that requires data to be sent or received from the server, there is a state transition from Setup to Connected. Examples of methods that cause the transition include:

openInputStream
openOutputStream
openDataInputStream
openDataOutputStream
getLength
getType
getDate
getExpiration

And while the connection is open, some of these methods that may be invoked:

getURL
getProtocol
getHost
getPort

------------------------------------------------------------
要注意的问题:
开发中遇到个很头疼的问�? 与服务器通信write()数据时报java.io.IOException: Couldn't write to socket.
但是服务器抓不到��M��? 一开始怀疑是�q�徏立连接出的问�? 实际上服务器抓不到包也有可能是流在没有close的时候就已经报错�?
�?
conn.open("url");
out = conn.openDataOutputStream();//此时��进行与服务器的三次握手;
//但是如果在out.close()之前出现异常服务器是抓不��C�Q何包�?br /> out.write(byte[] bb);

关于�q�个的解释应该是��的�~�冲机制.
所以正��的写法应该是捕捉到异常之后在catch块中把流close�?strong>.
服务器端开发�h员一般会说收不到包所以连接有问题,会把责�Q推给客户�?抓住�q�个证据在跟服务器端的同事扯皮时��处于有利的位置,嘎嘎.
�q�有��是要多做小实验, 注意代码要规范严�?

发现的几个问�?
1. java.io.IOException: Couldn't write to socket

2. java.io.IOException: Couldn't read from socket

CMNET联网�Ҏ��:

CMWAP联网�Ҏ��:

�U�d��资费��늚�处理:

一个通用的HTTP�q�接��装:

LukeW 2008-11-04 16:22 发表评论

HTTP协议中的Tranfer-Encoding�Q�chunked�~�码解析

LukeW — Wed, 24 Sep 2008 10:03:00 GMT

    当不能预先确定报文体的长度时�Q�不可能在头中包含Content-Length域来指明报文体长度，此时��需要通过Transfer-Encoding域来��定报文体长度�?br />     通常情况下，Transfer-Encoding域的值应当�ؓchunked,表明采用chunked�~�码方式来进行报文体的传输。chunked�~�码是HTTP/1.1 RFC里定义的一�U�编码方式，因此所有的HTTP/1.1应用都应当支持此方式�?br />     chunked�~�码的基本方法是��大块数据分解成多块��数据，每块都可以自指定长度�Q�其具体格式如下�Q�BNF文法�Q?
    Chunked-Body   = *chunk            //0臛_��个chunk
                     last-chunk         //最后一个chunk
                     trailer            //��N��
                     CRLF               //�l�束标记�W?br />
   chunk          = chunk-size [ chunk-extension ] CRLF
                        chunk-data CRLF
   chunk-size     = 1*HEX
   last-chunk     = 1*("0") [ chunk-extension ] CRLF

   chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
   chunk-ext-name = token
   chunk-ext-val = token | quoted-string
   chunk-data     = chunk-size(OCTET)
   trailer        = *(entity-header CRLF)

    解释�Q?br />     Chunked-Body表示�l�过chunked�~�码后的报文体。报文体可以分�ؓchunk, last-chunk�Q�trailer和结束符四部分。chunk的数量在报文体中最��可以�ؓ0�Q�无上限�Q�每个chunk的长度是自指定的�Q�即�Q��v始的�? 据必然是16�q�制数字的字�W�串�Q�代表后面chunk-data的长度（字节敎ͼ�。这�?6�q�制的字�W�串�W�一个字�W�如果是“0”�Q�则表示chunk- size�?�Q�该chunk为last-chunk,无chunk-data部分。可选的chunk-extension由通信双方自行��定�Q�如果接收�? 不理解它的意义，可以忽略�?br />     trailer是附加的在尾部的额外头域�Q�通常包含一些元数据�Q�metadata, meta means "about information"�Q�，�q�些头域可以在解码后附加在现有头域之后�?br />     实例分析�Q?br />     下面分析用ethereal抓包使用Firefox与某�|�站通信的结果（从头域结束符后开始）�Q?br /> Address 0.......................... f
000c0                              31
000d0    66 66 63 0d 0a ...............   // ASCII�?1ffc"r"n, chunk-data数据起始地址�?00d5
         很明显，“1ffc”为第一个chunk的chunk-size,转换为int�?188.�׃��1ffc后马上就�?br />          CRLF,因此没有chunk-extension.chunk-data的�v始地址�?00d5, 计算可知下一块chunk的�v�?br />        地址�?00d5+1ffc + 2=020d3,如下�Q?br /> 020d0    .. 0d 0a 31 66 66 63 0d 0a .... // ASCII�?"r"n1ffc"r"n
         前一�?d0a是上一个chunk的结束标记符�Q�后一�?d0a则是chunk-size和chunk-data的分隔符�?br />        此块chunk的长度同样�ؓ8188, 依次�c�L��Q�直到最后一�?br /> 100e0                        0d 0a 31
100f0    65 61 39 0d 0a......            //ASII码："r"n"1ea9"r"n
       此块长度�?x1ea9 = 7849, 下一块�v始�ؓ100f5 + 1ea9 + 2 = 11fa0,如下�Q?br /> 100a0    30 0d 0a 0d 0a                  //ASCII码：0"r"n"r"n
       “0”说明当前chunk为last-chunk, �W�一�?d 0a为chunk�l�束�W�。第二个0d0a说明没有trailer部分�Q�整个Chunk-body�l�束�?br />     解码��程�Q?br />     对chunked�~�码�q�行解码的目的是��分块的chunk-data整合恢复成一块作为报文体�Q�同时记录此块体的长度�?br />     RFC2616中附带的解码��程如下�Q?伪代码）
    length := 0         //长度计数器置0
    read chunk-size, chunk-extension (if any) and CRLF      //��d��chunk-size, chunk-extension
                                                          //和CRLF
    while(chunk-size > 0 )   {            //表明不是last-chunk
          read chunk-data and CRLF            //读chunk-size大小的chunk-data,skip CRLF
          append chunk-data to entity-body   //��此块chunk-data�q�加到entity-body�?br />           read chunk-size and CRLF          //��d��新chunk的chunk-size �?CRLF
    }
    read entity-header      //entity-header的格式�ؓname:valueCRLF,如果为空卛_��有CRLF
    while �Q�entity-header not empty)   //卻I��不是只有CRLF的空�?br />     {
       append entity-header to existing header fields
       read entity-header
    }
    Content-Length:=length      //��整个解码流�E�结束后计算得到的新报文体length
                               //作�ؓContent-Length域的值写入报文中
    Remove "chunked" from Transfer-Encoding //同时从Transfer-Encoding中域值去除chunked�q�个标记
    length最后的值实际�ؓ所有chunk的chunk-size之和�Q�在上面的抓包实例中�Q�一共有八块chunk-size�?x1ffc(8188)的chunk,剩下一块�ؓ0x1ea9(7849),加�v来一�?3353字节�?br />     注：对于上面例子中前几个chunk的大��都�?188,可能是因�?"1ffc" 4字节�Q?"r"n"2字节�Q�加上块��一�?"r"n"2字节一�?字节�Q�因此一个chunk整体�?196,正好可能是发送端一�ơTCP发送的�~�存大小�?

LukeW 2008-09-24 18:03 发表评论

HTTP Connections

LukeW — Wed, 24 Sep 2008 10:01:00 GMT

HTTP Connections

最�q�初涉网�l�编�E�，分析了下HTTP协议�Q�下面�ؓ�W�一��关于HTTP�q�接控制斚w��的学习日志，主要参考RFC2616�Q�肯定有疏漏之处�Q�还望指出�?br /> HTTP协议是位于传输层之上的应用层协议�Q�其�|�络层基��通常是TCP协议。TCP协议是面向连接和��的�Q�因此连接的状态和控制对于HTTP协议而言相当重要。同�Ӟ��HTTP是基于报文的�Q�因此如何确定报文长度也是协议中比较重要的一炏V�?br /> Persistent Connections持久�q�接
目的
    在��用持久连接前�Q�HTTP协议规定��取每个URL资源都需要��用单独的一个TCP�q�接�Q�这增加了HTTP服务端的负蝲�Q�引起互联网拥塞。例如内嵌图片以及其他类似数据的使用要求一个客��L��在很短时间内向同一个服务端发�v多个��h��?br /> 使用持久�q�接的优�?
减少TCP�q�接数量
在一个连接上实现HTTP��h��和应�{�的��水�Q�即允许客户端发出多个请求，而不必在接收到前一��h��的应�{�后才发��Z��一��h��Q�极大减��时间消�?br /> 后箋��h��延迟减少�Q�无需再在TCP握手上耗时
可以更加优雅地实现HTTP协议�Q�由于持�l�连接的存在无需报告错误后无需关闭�q�接�Q�因此客��L��可��用最新的协议�Ҏ��发��求，如果接收到表�C�错误的应答�Q�则换用更旧的语义�?br />
��M��描述
HTTP/1.1和之前版本的显著区别是HTTP/1.1默认使用持久�q�接。即�Q�除非服务端在应�{�中明确指出�Q�客��L��应当假定服务端会�l�持一个持久连接，即��从服务端收到的应�{�是报告错误�?br /> �? 久连接对关闭TCP�q�接的行为提供信号量机制支持。这个信号量是在HTTP头中的Connection域设�|�，注意Client向Proxy发出��h��时该域可能被Proxy-Connection域替换。一旦close信号被表明，客户端绝不能再通过该连接发送更多的��h��?br />
协商(Negotiation)
HTTP/1.1 服务端可以假定HTTP/1.1客户端会�l�持持久�q�接�Q�除非请求中Connection域的值是"close".同样的，如果服务端打��在送出应答后立�? 关闭�q�接�Q�它应当在应�{�中包含同样的Connection域�?TCP�q�接关闭是双向的,此时TCP�q�入半关闭状�?
同样的，HTTP/1.1客户端可以期望连接是持久的，除非如前所�q�收到表�C��接关闭的应答。当�Ӟ��也可以主动发��Z��个包含Connection:close的请求以表明�l�止�q�接�?br /> 无论客户端还是服务端发出的报文包含Connection:close�Q�则该请求均��接上的最后一个请�?服务端发出此应答后关闭，因此不可能接收更多的��h��)
报文传输长度
    ��Z��证持久性，�q�接上的报文都必��L��一个自定义的报文传输长�?否则必须通过�q�接的关闭表�C�报文结束，因�ؓTCP�q�接是面向流�?�Q�确定的规则按优先��由高��C��排列如下�Q?br />     报文传输长度指报文中出现的报文体的长�?卻I��不包括头长度�Q�因为报文头的结束可通过�q�箋两个CRLF��定�Q?br /> 1.��M��l�不能包含报文体(�?xx,204,304)的应�{�消息��L��以头域后的第一个空行结�?无视头中所有的entity�c�d��域的讄��Q�包括Content-Length域�?br /> 2.Transfer-Encoding域出玎ͼ�其��gؓ�?identify"以外的其他��|��则用"chunked"传输�~�码方式��定传输长度�Q�具体方式留待下��分析�?br /> 3.Content- Length域出玎ͼ�且Transfer-Encoding域未出现(出现则忽略Content-Length�?。Content-Length域的�? 为十�q�制数的字节序，如Content-Length�Q?234�Q�则1�?�?�?是分别作��Z��个octet传输的，因此需要atoi转换成数倹{�?br /> 4.如果报文使用�?multipart/byteranges"的媒体类型，且没对传输长度做前面的指明，则这�U�自分割的媒体类型定义了传输长度。具体参见Range头域的说明�?br /> 5.服务端关闭连�?此方法不可用于客��L��发出的请求报文，因�ؓ客户端关闭连接则使得服务端无法发送应�{?.
    ��Z��持和HTTP/1.0的兼�Ҏ�? 包含报文体的HTTP/1.1��h��必须包含合法的Content-Length头域,除非明确知道服务端是HTTP/1.1兼容�?如果��h��包含消息�? 而没有Content-Length�?那么如果服务端无法确定消息长度时,它会�q�回400(无效��h��),或者坚持获取合法Content-Length 而返�?11(要求包含长度).

    所有接收实体的HTTP/1.1应用�E�序必须接受"chunked"传输�~�码, �q�样允许当报文长度无法预先确定时可以�q�用此机制获取报文长�?
    报文不能同时包含Content-Length头域和非"identity" Transfer-Encoding.如果出现�? Content-Length域必��被忽略.
    当Content-Length域在允许报文体的报文中存在时, 其域值必��M��格等于消息体中的8比特字节.HTTP/1.1 user agent 必须在接收�ƈ��到一个错误的长度时提醒用�?
    以上�Ҏ��中，最常见的还是��用Content-Length域表�C�报文体长度�Q�Transfer-Encoding需要按格式解码才能�q�原出发送编码前的报文�?br />
��水
    支持持久�q�接的客��L��可以��水发送请求，服务端必��L��发送的��序发送应�{��?br />     假定持久�q�接和连接后卛_��水的客��L��应当做好在第一�ơ流水失败后重新��试此连接。在�q�样的尝试中�Q�在��定�q�接是持久的之前�Q�客��L��不能再流水�?br />     客户端同样必��d��备好在服务端送回所有相兛_��{�前��关闭连接时重发��h��?br />     不应��水non-idempotent�Ҏ��

Proxy Servers
    对于代理服务端而言�Q�正��实现Connection头域指定的属性尤为重要�?br />     代理服务端必��d��立通告它的客户端和�q�接的原始服务端持久�q�接的属性，每个持久�q�接讄��仅针对一个传输连接�?br />
实践考量
    ��时��|��服务端通常会�ؓ每个�q�接�l�护一个定时器�Q�一旦某个连接不�z�跃��过一定时间��|��服务端会关闭此连接。考虑��C��个客��L��可能通过代理服务端发出更多连接，代理服务端通常会将��时��D��|�得更高�?br />     �q�有一些关于从异步关闭中恢复的讨论�?br />
报文传输要求
    使用TCP��控制来解决服务端��时负载过高问题，而不是简单的依赖客户端重�q�而关闭连接�?br />     监视�q�接情况以获取错误状态消�?br />     关于使用100(�l�箋)状态码
    100状态码用于客户端发送请求体之前��试是否可以发送该��h��Q�对于Proxy�Q�有以下要求�Q?br /> 1.如果代理服务端接收到包含Expect头域��gؓ"100-continue"的请�? 而不明确知道下一��x��务不支持HTTP/1.1以上版本, 则它必须转发�q�个��h��, 包括Expect头域.
2.如果代理知道下一��x��务端为HTTP/1.0或者更低版�? 则它不能转发此请�? 且必��M��407应答客户�?
3.如果明确知道发出��h��的客��L��版本为HTTP/1.0或者更低，则代理服务端�l�不能�{�?00应答,�q�条规则凌驾于�{�?xx应答的一般准�?

Connection头域说明
BNF文法�Q?br />     Connection = "Connection" ":" 1#(connection-token)
    connection-token = token
    Connection头域中的token用于指定对于特定�q�接有意义的选项�Q�因此proxy在�{发前要扫描此域，从头中去除和token同名的域。例如Connection:Range,则要��L��Range域�?br />     HTTP/1.1定义了close�q�个token�Q�发送者用此token表示在完成这个报文所属请�?应答的收发后�q�接��关闭�?br />

LukeW 2008-09-24 18:01 发表评论

LukeW — Wed, 24 Sep 2008 09:57:00 GMT

一些讨�?
http://topic.csdn.net/t/20061214/22/5231907.html

LukeW 2008-09-24 17:57 发表评论

LukeW — Wed, 10 Sep 2008 04:05:00 GMT

HTTP�Q�HyperTextTransferProtocol�Q�是��文本传输协议的�~�写�Q�它用于传送WWW方式的数据，关于HTTP 协议的详�l�内容请�? 考RFC2616。HTTP协议采用了请�?响应模型。客��L��向服务器发送一个请求，��h��头包含请求的�Ҏ��、URI、协议版本、以及包含请求修饰符、客�? 信息和内容的�c�M��于MIME的消息结构。服务器以一个状态行作�ؓ响应�Q�相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息�? 及可能的实体内容�?

通常HTTP消息包括客户机向服务器的��h��消息和服务器向客��h��的响应消息。这两种�c�d��的消息由一个�v始行�Q? 一个或者多个头域，一个只是头域结束的�I��和可选的消息体组成�?span style="color: #ff9658;">HTTP的头域包括通用��_��h��_��响应头和实体头四个部�?/span>。每个头域由一个域名，冒号�Q?�Q�和域��g��部分�l�成。域名是大小写无关的�Q�域值前可以��d��M��数量的空格符�Q�头域可以被扩展为多行，在每行开始处�Q��用至��一个空格或制表�W��?

通用头域
通用�?域包含请求和响应消息都支持的头域�Q�通用头域包含Cache-Control�? Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此�? 展，如果存在不支持的通用头域�Q�一般将会作为实体头域处理。下面简单介�l�几个在UPnP消息中��用的通用头域�?

　　Cache-Control头域
Cache -Control指定��h��和响应遵循的�~�存机制。在��h��消息或响应消息中讄�� Cache-Control�q�不会修改另一个消息处理过�E�中的缓存处理过�E�。请求时的缓存指令包括no-cache、no-store、max-age�? max-stale、min-fresh、only-if-cached�Q�响应消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下：

Public指示响应可被��M��~�存区缓存�?
Private指示对于单个用户的整个或部分响应消息�Q�不能被�׃�n�~�存处理。这允许服务器仅仅描�q�当用户的部分响应消息，此响应消息对于其他用��L��h��无效�?
no-cache指示��h��或响应消息不能缓�?
no-store用于防止重要的信息被无意的发布。在��h��消息中发送将使得��h��和响应消息都不��用缓存�?
max-age指示客户机可以接收生存期不大于指定时��_��以秒为单位）的响应�?
min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应�?
max-stale指示客户机可以接收超��时期间的响应消息。如果指定max-stale消息的��|��那么客户机可以接收超��时期指定��g��内的响应消息�?

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

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

��h��消息
��h��消息的第一行�ؓ下面的格式：
MethodSPRequest-URISPHTTP-VersionCRLFMethod 表示对于Request-URI完成的方法，�q�个字段是大��写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE�? TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET�Ҏ��取回由Request-URI标识的信息�? HEAD�Ҏ��也是取回由Request-URI标识的信息，只是可以在响应时�Q�不�q�回消息体。POST�Ҏ��可以��h��服务器接收包含在��h��中的实体信息�Q�可以用于提交表单，向新�ȝ��、BBS、邮件群�l�和数据库发送消息�?

SP表示�I�格。Request-URI遵��@URI格式�Q�在此字�D? 为星 ��P��*�Q�时�Q�说明请求�ƈ不用于某个特定的资源地址�Q�而是用于服务器本�w�。HTTP- Version表示支持的HTTP版本�Q�例如�ؓHTTP/1.1。CRLF表示换行回�R�W�。请求头域允许客��L��向服务器传递关于请求或者关于客��h��的附�? 信息。请求头域可能包含下列字�D�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。对��h��头域的扩展要求通讯双方都支持，如果存在不支持的�? 求头域，一般将会作为实体头域处理�?

　　典型的请求消息：
GET http://download.microtool.de:80/somedata.exe
Host: download.microtool.de
Accept:*/*
Pragma: no-cache
Cache-Control: no-cache
Referer: http://download.microtool.de/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-

上例�W�一行表�C�HTTP客户端（可能是浏览器、下载程序）通过GET�Ҏ��获得指定URL下的文�g。棕色的部分表示��h��头域的信息，�l�色的部分表�C�通用头部分�?

　　Host头域
　　Host头域指定��h��资源的Intenet��L��和端口号�Q�必��表�C��求url的原始服务器或网关的位置。HTTP/1.1��h��必须包含��L��头域�Q�否则系�l�会�?00状态码�q�回�?

　　Referer头域
Referer 头域允许客户端指定请求uri的源资源地址�Q�这可以允许服务器生成回退链表�Q�可用来登陆、优化cache�{�。他也允许废除的或错误的�q�接�׃��l�护的目的被 �q�踪。如果请求的uri没有自己的uri地址�Q�Referer不能被发送。如果指定的是部分uri地址�Q�则此地址应该是一个相对地址�?

　　Range头域
Range头域可以��h��实体的一个或者多个子范围。例如，
表示�?00个字节：bytes=0-499
表示�W�二�?00字节�Q�bytes=500-999
表示最�?00个字节：bytes=-500
表示500字节以后的范��_��bytes=500-
�W�一个和最后一个字节：bytes=0-0,-1
同时指定几个范围�Q�bytes=500-600,601-999

但是服务器可以忽略此��h��_��如果无条件GET包含Range��h��_��响应会以状态码206�Q�PartialContent�Q�返回而不是以200 �Q�OK�Q��?

　　User-Agent头域
User-Agent头域的内容包含发��求的用户信息�?

响应消息
响应消息的第一行�ؓ下面的格式：
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF

HTTP -Version表示支持的HTTP版本�Q�例如�ؓHTTP/1.1。Status- Code是一个三个数字的�l�果代码。Reason-Phrase�l�Status-Code提供一个简单的文本描述。Status-Code主要用于机器�? 动识别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的�c�d��Q�后两个数字没有分类的作用。第一个数字可能取5个不同的��|��

1xx:信息响应�c�，表示接收到请求�ƈ且��l�处�?
2xx:处理成功响应�c�，表示动作被成功接收、理解和接受
3xx:重定向响应类�Q��ؓ了完成指定的动作�Q�必��L��受进一步处�?
4xx:客户端错误，客户��h��包含语法错误或者是不能正确执行
5xx:服务端错误，服务器不能正��执行一个正��的��h��

响应头域允许服务器传递不能放在状态行的附加信息，�q�些域主要描�q�服务器的信息和 Request-URI�q�一步的信息。响应头域包含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

上例�W�一行表�C�HTTP服务端响应一个GET�Ҏ��。棕色的部分表示响应头域的信息，�l�色的部分表�C�通用头部分，�U�色的部分表�C�实体头域的信息�?

　　Location响应�?/strong>
Location响应头用于重定向接收者到一个新URI地址�?

　　Server响应�?/strong>
Server响应头包含处理请求的原始服务器的软�g信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序�?

　　实体
��h��消息和响应消息都可以包含实体信息�Q�实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括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允许客户端定义新的实�? ��_��但是�q�些域可能无法未接受方识别。实体可以是一个经�q�编码的字节��，它的�~�码方式由Content-Encoding或Content-Type�? 义，它的长度由Content-Length或Content-Range定义�?

　　Content-Type实体�?/strong>
Content-Type实体头用于向接收�Ҏ��C�实体的介质�c�d��Q�指定HEAD�Ҏ��送到接收方的实体介质�c�d��Q�或GET�Ҏ��发送的��h��介质�c�d�� Content-Range实体�?
Content-Range实体头用于指定整个实体中的一部分的插入位�|�，他也指示了整个实体的长度。在服务器向客户�q�回一个部分响应，它必��L��q�响应覆盖的范围和整个实体长度。一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth

例如�Q�传送头500个字节次字段的�Ş式：Content-Range:bytes0- 499/1234如果一个http消息包含此节�Q�例如，对范围请求的响应或对一�p�d��范围的重叠请求）�Q�Content-Range表示传送的范围�Q? Content-Length表示实际传送的字节数�?

　　Last-modified实体�?/strong>

应答�? 说明

Allow 服务器支持哪些请求方法（如GET、POST�{�）�?/td>

Content-Encoding �? 档的�~�码�Q�Encode�Q�方法。只有在解码之后才可以得到Content-Type头指定的内容�c�d��。利用gzip压羃文档能够显著地减��HTML文档�? 下蝲旉��。Java的GZIPOutputStream可以很方便地�q�行gzip压羃�Q�但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding��_��即request.getHeader("Accept- Encoding")�Q�检查浏览器是否支持gzip�Q��ؓ支持gzip的浏览器�q�回�l�gzip压羃的HTML��面�Q��ؓ其他��览器返回普通页面�?/td>

Content-Length �? �C�内定w��度。只有当��览器��用持久HTTP�q�接时才需要这个数据。如果你惌��利用持久�q�接的优势，可以把输出文档写�? ByteArrayOutputStram�Q�完成后查看其大��，然后把该值放入Content-Length��_��最后通过 byteArrayStream.writeTo(response.getOutputStream()发送内宏V�?/td>

Content-Type 表示后面的文档属于什么MIME�c�d��。Servlet默认为text/plain�Q�但通常需要显式地指定为text/html。由于经常要讄��Content-Type�Q�因此HttpServletResponse提供了一个专用的�Ҏ��setContentTyep�?

Date 当前的GMT旉��。你可以用setDateHeader来设�|�这个头以避免�{换时间格式的�ȝ��?

Expires 应该在什么时候认为文档已�l�过期，从而不再缓存它�Q?/td>

Last-Modified �? 档的最后改动时间。客户可以通过If-Modified-Since��h��头提供一个日期，该请求将被视��Z��个条件GET�Q�只有改动时间迟于指定时间的文档才会�q�回�Q�否则返回一�?04�Q�Not Modified�Q�状态。Last-Modified也可用setDateHeader�Ҏ��来设�|��?/td>

Location 表示客户应当到哪里去提取文档。Location通常不是直接讄��的，而是通过HttpServletResponse的sendRedirect�Ҏ��Q�该�Ҏ��同时讄��状态代码�ؓ302�?

Refresh 表示��览器应该在多少旉��之后��h��文档�Q�以�U�计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器��d��指定的页面�?
�? 意这�U�功能通常是通过讄��HTML��面HEAD区的�Q�META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"�Q�实玎ͼ��q�是因�ؓ�Q�自动刷新或重定向对于那些不能��用CGI或Servlet�? HTML�~�写者十分重要。但是，对于Servlet来说�Q�直接设�|�Refresh头更加方�ѝ�?

注意Refresh的意义是“N�U�之�? ��h��本页面或讉K��指定��面”�Q�而不�?#8220;每隔N�U�刷新本��面或访问指定页�?#8221;。因此，�q�箋��h��要求每次都发送一个Refresh��_��而发�?04状态代码则可以��L��览器��l�刷斎ͼ�不管是��用Refresh头还是＜META HTTP-EQUIV="Refresh" ...�Q��?

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

Server 服务器名字。Servlet一般不讄��q�个��|��而是由Web服务器自��p��|��?/td>

Set-Cookie 讄��和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)�Q�而是应��用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie讄��的讨论�?/td>

WWW-Authenticate �? 户应该在Authorization头中提供什么类型的授权信息�Q�在包含401�Q�Unauthorized�Q�状态行的应�{�中�q�个头是必需的。例如， response.setHeader("WWW-Authenticate", "BASIC realm=�Q?executives�Q?")�?
注意Servlet一般不�q�行�q�方面的处理�Q�而是让Web服务器的专门机制来控制受密码保护��面的访问（例如.htaccess�Q��?/td>

LukeW 2008-09-10 12:05 发表评论

LukeW — Wed, 20 Aug 2008 05:58:00 GMT
HTTP客户�E�序�Q�例如浏览器�Q�，向服务器发送请求的时候必��L��明请求类型（一般是GET或者POST�Q�。如有必要，客户�E�序�q�可以选择发送其他的��h�� 头。大多数��h��头�ƈ不是必需的，但Content-Length除外。对于POST��h��来说Content-Length必须出现�?br />
下面是一些最常见的请求头�Q?br />
Accept�Q�浏览器可接受的MIME�c�d��?br /> Accept-Charset�Q�浏览器可接受的字符集�?br /> Accept-Encoding�Q�浏览器能够�q�行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器�q�回�l�gzip�~�码的HTML��面。许多情形下�q�可以减��?�?0倍的下蝲旉��?br /> Accept-Language�Q�浏览器所希望的语�a��U�类�Q�当服务器能够提供一�U�以上的语言版本时要用到�?br /> Authorization�Q�授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中�?br /> Connection�Q? 表示是否需要持久连接。如果Servlet看到�q�里的��gؓ“Keep-Alive”�Q�或者看到请求��用的是HTTP 1.1�Q�HTTP 1.1默认�q�行持久�q�接�Q�，它就可以利用持久�q�接的优点，当页面包含多个元素时�Q�例如Applet�Q�图片）�Q�显著地减少下蝲所需要的旉��。要实现�q�一点， Servlet需要在应答中发送一个Content-Length��_��最��单的实现�Ҏ��是：先把内容写入ByteArrayOutputStream�Q�然后在正式写出内容之前计算它的大小�?br /> Content-Length�Q�表�C��求消息正文的长度�?br /> Cookie�Q�这是最重要的请求头信息之一�Q�参见后面《Cookie处理》一章中的讨论�?br /> From�Q�请求发送者的email地址�Q�由一些特�D�的Web客户�E�序使用�Q�浏览器不会用到它�?br /> Host�Q�初始URL中的��L��和端口�?br /> If-Modified-Since�Q�只有当所��h��的内容在指定的日期之后又�l�过修改才返回它�Q�否则返�?04“Not Modified”应答�?br /> Pragma�Q�指�?#8220;no-cache”��D��C�服务器必须�q�回一个刷新后的文档，即��它是代理服务器而且已经有了��面的本地拷贝�?br />
JAVA手机�|�[www.cnjm.net]

Referer�Q�包含一个URL�Q�用户从该URL代表的页面出发访问当前请求的��面�?br /> User-Agent�Q�浏览器�c�d��Q�如果Servlet�q�回的内容与��览器类型有兛_��该值非常有用�?br /> UA-Pixels�Q�UA-Color�Q�UA-OS�Q�UA-CPU�Q�由某些版本的IE��览器所发送的非标准的��h��_��表示屏幕大小、颜色深度、操作系�l�和CPU�c�d��?br /> 有关HTTP头完整、详�l�的说明�Q�请参见http://www.w3.org/Protocols/ 的HTTP规范�?br />

java ��d��Ҏ��

Enumeration headerNames = request.getHeaderNames();
         while(headerNames.hasMoreElements()) {
             String headerName = (String)headerNames.nextElement();
             out.println("
"+headerName+" "+request.getHeader(headerName)+"
");
         }

LukeW 2008-08-20 13:58 发表评论

应答�?	说明
Allow	服务器支持哪些请求方法（如GET、POST�{�）�?/td>
Content-Encoding	�? 档的�~�码�Q�Encode�Q�方法。只有在解码之后才可以得到Content-Type头指定的内容�c�d��。利用gzip压羃文档能够显著地减��HTML文档�? 下蝲旉��。Java的GZIPOutputStream可以很方便地�q�行gzip压羃�Q�但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding��_��即request.getHeader("Accept- Encoding")�Q�检查浏览器是否支持gzip�Q��ؓ支持gzip的浏览器�q�回�l�gzip压羃的HTML��面�Q��ؓ其他��览器返回普通页面�?/td>
Content-Length	�? �C�内定w��度。只有当��览器��用持久HTTP�q�接时才需要这个数据。如果你惌��利用持久�q�接的优势，可以把输出文档写�? ByteArrayOutputStram�Q�完成后查看其大��，然后把该值放入Content-Length��_��最后通过 byteArrayStream.writeTo(response.getOutputStream()发送内宏V�?/td>
Content-Type	表示后面的文档属于什么MIME�c�d��。Servlet默认为text/plain�Q�但通常需要显式地指定为text/html。由于经常要讄��Content-Type�Q�因此HttpServletResponse提供了一个专用的�Ҏ��setContentTyep�?
Date	当前的GMT旉��。你可以用setDateHeader来设�\|�这个头以避免�{换时间格式的�ȝ��?
Expires	应该在什么时候认为文档已�l�过期，从而不再缓存它�Q?/td>
Last-Modified	�? 档的最后改动时间。客户可以通过If-Modified-Since��h��头提供一个日期，该请求将被视��Z��个条件GET�Q�只有改动时间迟于指定时间的文档才会�q�回�Q�否则返回一�?04�Q�Not Modified�Q�状态。Last-Modified也可用setDateHeader�Ҏ��来设�\|��?/td>
Location	表示客户应当到哪里去提取文档。Location通常不是直接讄��的，而是通过HttpServletResponse的sendRedirect�Ҏ��Q�该�Ҏ��同时讄��状态代码�ؓ302�?
Refresh	表示��览器应该在多少旉��之后��h��文档�Q�以�U�计。除了刷新当前文档之外，你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器��d��指定的页面�? �? 意这�U�功能通常是通过讄��HTML��面HEAD区的�Q�META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path"�Q�实玎ͼ��q�是因�ؓ�Q�自动刷新或重定向对于那些不能��用CGI或Servlet�? HTML�~�写者十分重要。但是，对于Servlet来说�Q�直接设�\|�Refresh头更加方�ѝ�? 注意Refresh的意义是“N�U�之�? ��h��本页面或讉K��指定��面”�Q�而不�?#8220;每隔N�U�刷新本��面或访问指定页�?#8221;。因此，�q�箋��h��要求每次都发送一个Refresh��_��而发�?04状态代码则可以��L��览器��l�刷斎ͼ�不管是��用Refresh头还是＜META HTTP-EQUIV="Refresh" ...�Q��? 注意Refresh头不属于HTTP 1.1正式规范的一部分�Q�而是一个扩展，但Netscape和IE都支持它�?/td>
Server	服务器名字。Servlet一般不讄��q�个��\|��而是由Web服务器自��p��\|��?/td>
Set-Cookie	讄��和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...)�Q�而是应��用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie讄��的讨论�?/td>
WWW-Authenticate	�? 户应该在Authorization头中提供什么类型的授权信息�Q�在包含401�Q�Unauthorized�Q�状态行的应�{�中�q�个头是必需的。例如， response.setHeader("WWW-Authenticate", "BASIC realm=�Q?executives�Q?")�? 注意Servlet一般不�q�行�q�方面的处理�Q�而是让Web服务器的专门机制来控制受密码保护��面的访问（例如.htaccess�Q��?/td>