INTRODUCTION
Cookies are a general mechanism which server side connections (such as
CGI scripts) can use to both store and retrieve information on the
client side of the connection. The addition of a simple, persistent,
client-side state significantly extends the capabilities of Web-based
client/server applications.
OVERVIEW
A server, when returning an HTTP object to a client, may also send a
piece of state information which the client will store. Included in
that state object is a description of the range of URLs for which that
state is valid. Any future HTTP requests made by the client which fall
in that range will include a transmittal of the current value of the
state object from the client back to the server. The state object is
called a cookie, for no compelling reason.
This simple mechanism provides a powerful new tool which enables a host
of new types of applications to be written for web-based environments.
Shopping applications can now store information about the currently
selected items, for fee services can send back registration information
and free the client from retyping a user-id on next connection, sites
can store per-user preferences on the client, and have the client
supply those preferences every time that site is connected to.
SPECIFICATION
A cookie is introduced to the client by including a Set-Cookie header
as part of an HTTP response, typically this will be generated by a CGI
script.
Syntax of the Set-Cookie HTTP Response Header
This is the format a CGI script would use to add to the HTTP headers a
new piece of data which is to be stored by the client for later
retrieval.
Set-Cookie: NAME=VALUE; expires=DATE;
path=PATH; domain=DOMAIN_NAME; secure
NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and
white space. If there is a need to place such data in the name or
value, some encoding method such as URL style %XX encoding is
recommended, though no encoding is defined or required.
This is the only required attribute on the Set-Cookie header.
expires=DATE
The expires attribute specifies a date string that defines the valid
life time of that cookie. Once the expiration date has been reached,
the cookie will no longer be stored or given out.
The date string is formatted as:
Wdy, DD-Mon-YYYY HH:MM:SS GMT
This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the
variations that the only legal time zone is GMT and the separators
between the elements of the date must be dashes.
expires is an optional attribute. If not specified, the cookie will expire when the user's session ends.
Note: There is a bug in Netscape Navigator version 1.1 and earlier.
Only cookies whose path attribute is set explicitly to "/" will be
properly saved between sessions if they have an expires attribute.
domain=DOMAIN_NAME
When searching the cookie list for valid cookies, a comparison of the
domain attributes of the cookie is made with the Internet domain name
of the host from which the URL will be fetched. If there is a tail
match, then the cookie will go through path matching to see if it
should be sent. "Tail matching" means that domain attribute is matched
against the tail of the fully qualified domain name of the host. A
domain attribute of "acme.com" would match host names "anvil.acme.com"
as well as "shipping.crate.acme.com".
Only hosts within the specified domain can set a cookie for a domain
and domains must have at least two (2) or three (3) periods in them to
prevent domains of the form: ".com", ".edu", and "va.us". Any domain
that fails within one of the seven special top level domains listed
below only require two periods. Any other domain requires at least
three. The seven special top level domains are: "COM", "EDU", "NET",
"ORG", "GOV", "MIL", and "INT".
The default value of domain is the host name of the server which generated the cookie response.
path=PATH
The path attribute is used to specify the subset of URLs in a domain
for which the cookie is valid. If a cookie has already passed domain
matching, then the pathname component of the URL is compared with the
path attribute, and if there is a match, the cookie is considered valid
and is sent along with the URL request. The path "/foo" would match
"/foobar" and "/foo/bar.html". The path "/" is the most general path.
If the path is not specified, it as assumed to be the same path as the
document being described by the header which contains the cookie.
secure
If a cookie is marked secure, it will only be transmitted if the
communications channel with the host is a secure one. Currently this
means that secure cookies will only be sent to HTTPS (HTTP over SSL)
servers.
If secure is not specified, a cookie is considered safe to be sent in the clear over unsecured channels.
Syntax of the Cookie HTTP Request Header
When requesting a URL from an HTTP server, the browser will match the
URL against all cookies and if any of them match, a line containing the
name/value pairs of all matching cookies will be included in the HTTP
request. Here is the format of that line:
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...
Additional Notes
Multiple Set-Cookie headers can be issued in a single server response.
Instances of the same path and name will overwrite each other, with the
latest instance taking precedence. Instances of the same path but
different names will add additional mappings.
Setting the path to a higher-level value does not override other more
specific path mappings. If there are multiple matches for a given
cookie name, but with separate paths, all the matching cookies will be
sent. (See examples below.)
The expires header lets the client know when it is safe to purge the
mapping but the client is not required to do so. A client may also
delete a cookie before it's expiration date arrives if the number of
cookies exceeds its internal limits.
When sending cookies to a server, all cookies with a more specific path
mapping should be sent before cookies with less specific path mappings.
For example, a cookie "name1=foo" with a path mapping of "/" should be
sent after a cookie "name1=foo2" with a path mapping of "/bar" if they
are both to be sent.
There are limitations on the number of cookies that a client can store
at any one time. This is a specification of the minimum number of
cookies that a client should be prepared to receive and store.
300 total cookies
4 kilobytes per cookie, where the name and the OPAQUE_STRING combine to form the 4 kilobyte limit.
20 cookies per server or domain. (note that completely specified hosts
and domains are treated as separate entities and have a 20 cookie
limitation for each, not combined)
Servers should not expect clients to be able to exceed these limits.
When the 300 cookie limit or the 20 cookie per server limit is
exceeded, clients should delete the least recently used cookie. When a
cookie larger than 4 kilobytes is encountered the cookie should be
trimmed to fit, but the name should remain intact as long as it is less
than 4 kilobytes.
If a CGI script wishes to delete a cookie, it can do so by returning a
cookie with the same name, and an expires time which is in the past.
The path and name must match exactly in order for the expiring cookie
to replace the valid cookie. This requirement makes it difficult for
anyone but the originator of a cookie to delete a cookie.
When caching HTTP, as a proxy server might do, the Set-cookie response header should never be cached.
If a proxy server receives a response which contains a Set-cookie
header, it should propagate the Set-cookie header to the client,
regardless of whether the response was 304 (Not Modified) or 200 (OK).
Similarly, if a client request contains a Cookie: header, it should be
forwarded through a proxy, even if the conditional If-modified-since
request is being made.
EXAMPLES
Here are some sample exchanges which are designed to illustrate the use of cookies.
First Example transaction sequence:
Client requests a document, and receives in the response:
Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT
When client requests a URL in path "/" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE
Client requests a document, and receives in the response:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
When client requests a URL in path "/" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
Client receives:
Set-Cookie: SHIPPING=FEDEX; path=/foo
When client requests a URL in path "/" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
When client requests a URL in path "/foo" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX
Second Example transaction sequence:
Assume all mappings from above have been cleared.
Client receives:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
When client requests a URL in path "/" on this server, it sends:
Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001
Client receives:
Set-Cookie: PART_NUMBER=RIDING_ROCKET_0023; path=/ammo
When client requests a URL in path "/ammo" on this server, it sends:
Cookie: PART_NUMBER=RIDING_ROCKET_0023; PART_NUMBER=ROCKET_LAUNCHER_0001
NOTE: There are two name/value pairs named "PART_NUMBER" due to the
inheritance of the "/" mapping in addition to the "/ammo" mapping.
通过缺省方式创建的avd，模拟器起来后，访问系统自带的Browser，显示无法访问网络：Web page not available.
创建的avd的target无论是Android 1.1，还是Android 1.5都不行。
在sdk1.1下的模拟器是正常的。这是怎么回事？各位有无遇到类似的问题？
说明：本机无代理，FF访问网络正常
现在xp下能够正常访问网络了。浏览器和地图都正常可访问。但切换到ubuntu环境下，还是有问题：
ubuntu下用了代理，android的浏览器不能访问网络，但地图可以。
看来这个avd问题还挺多阿
今天碰到一个地图的BUG，显示地图时前几次正常，后来一直是蓝屏。删掉重建了一个avd，再发布就OK了。
I tried different way, but no connection to internet from emulator.
众所周知，CMWAP是一个网关，同时又是一个代理服务器，我们只知道
J2ME这样写是没有问题的
假设我请求的地址是http://www.uc.cn/a.do?url=http://www.iteye.com
httpConn = (HttpConnection) Connector.open(Common.stringAppend("http://10.0.0.172
/a.do?url=http://www.iteye.com", 3, true);
if (aProxy != null) {
httpConn.setRequestProperty("X-Online-Host", "www.uc.cn);
}
这样写，对于WTK，Nokia S40的处理机制。他们转换成Soket后是这么写的
SocketConnection socket =
(SocketConnection) javax.microedition.io.Connector.open("socket://10.0.0.172:80");
OutputStream os = socket.openOutputStream();
os.write(toByte("GET /a.do?url=http://www.iteye.com HTTP/1.1\r\n"));
os.write(toByte("Host: 10.0.0.172\r\n"));
os.write(toByte("X-Online-Host: www.uc.cn\r\n\r\n"));
网关对上面写法的处理并不能达到你的期望。
对于Socket层来说，我们应该处理成一个标准的代理方式，只有这样，才能达到我们期望的结果。
SocketConnection socket =
(SocketConnection) javax.microedition.io.Connector.open("socket://10.0.0.172:80");
OutputStream os = socket.openOutputStream();
os.write(toByte("GET http://10.0.0.172/a.do?url=http://www.iteye.com HTTP/1.1\r\n"));
os.write(toByte("Host: 10.0.0.172\r\n"));
os.write(toByte("X-Online-Host: www.uc.cn\r\n\r\n"));
这样写，就能达到我们想要的结果，而且这也是代理服务器的标准写法。
从上面的一些数据分析，我猜想移动网关的处理方式是：
我们以http://10.0.0.172/a.do?url=http://www.uc.cn/ 的方式进行处理
处理步骤
1. 获取host字段，J2ME的HttpConnection send header是host: 10.0.0.172,
那么移动先分析此字段。
2. 如果Host字段是10.0.0.172, 那么会去查找X-Online-Host字段，并且代理发送的时候把Host植替换成X-Online-Host的植，
如果非10.0.0.172，则直接走HTTP标准的代理方式。
3. 如果Host字段是10.0.0.172, CMWAP还会分析URI(/a.do?url=http://www.uc.cn/)。如果你的URI里面带有http://关键字的话
那么问题就会出现了，它会认为http://是host具备的字段，因此它会分析http://www.uc.cn并且把host后面的字符传当成URI。
最终导致了你请求以http://10.0.0.172/a.do?url=http://www.uc.cn/ 变成了请求以http://10.0.0.172/了，服务一般会return
500 内部错误。
具体大家可以编写想过的代码试试