and look at the source code first
/**
*
* Creates a cookie, a small amount of information sent by a servlet to
* a Web browser, saved by the browser, and later sent back to the server.
* A cookie's value can uniquely
* identify a client, so cookies are commonly used for session management.
*
* <p>A cookie has a name, a single value, and optional attributes
* such as a comment, path and domain qualifiers, a maximum age, and a
* version number. Some Web browsers have bugs in how they handle the
* optional attributes, so use them sparingly to improve the interoperability
* of your servlets.
*
* <p>The servlet sends cookies to the browser by using the
* {@link HttpServletResponse#addCookie} method, which adds
* fields to HTTP response headers to send cookies to the
* browser, one at a time. The browser is expected to
* support 20 cookies for each Web server, 300 cookies total, and
* may limit cookie size to 4 KB each.
*
* <p>The browser returns cookies to the servlet by adding
* fields to HTTP request headers. Cookies can be retrieved
* from a request by using the {@link HttpServletRequest#getCookies} method.
* Several cookies might have the same name but different path attributes.
*
* <p>Cookies affect the caching of the Web pages that use them.
* HTTP 1.0 does not cache pages that use cookies created with
* this class. This class does not support the cache control
* defined with HTTP 1.1.
*
* <p>This class supports both the Version 0 (by Netscape) and Version 1
* (by RFC 2109) cookie specifications. By default, cookies are
* created using Version 0 to ensure the best interoperability.
*
*
* @author Various
*/
// XXX would implement java.io.Serializable too, but can't do that
// so long as sun.servlet.* must run on older JDK 1.02 JVMs which
// don't include that support.
public class Cookie implements Cloneable {
private static final String LSTRING_FILE =
"javax.servlet.http.LocalStrings";
private static ResourceBundle lStrings =
ResourceBundle.getBundle(LSTRING_FILE);
//
// The value of the cookie itself.
//
private String name; // NAME= ... "$Name" style is reserved
private String value; // value of NAME
//
// Attributes encoded in the header's cookie fields.
//
private String comment; // ;Comment=VALUE ... describes cookie's use
// ;Discard ... implied by maxAge < 0
private String domain; // ;Domain=VALUE ... domain that sees cookie
private int maxAge = -1; // ;Max-Age=VALUE ... cookies auto-expire
private String path; // ;Path=VALUE ... URLs that see the cookie
private boolean secure; // ;Secure ... e.g. use SSL
private int version = 0; // ;Version=1 ... means RFC 2109++ style
The first comparison with Session
Ten years ago, when business was processed on a single machine, when there were not many clusters, Session was used more. Now any service is deployed in a cluster. Considering the synchronization of multi-node memory, sessions are not used much. HTTP is stateless, retains user information, and uses session sessions. There is too much information on the Internet, so I won't go into details.
The second API is too
simple, so I won't repeat it . It is a Cookie[] so this key can be repeated. However, cookies are often used as maps, so it is recommended to encapsulate the cookie operation. The attribute comment is the description of the stored key value. It is nothing special. The life cycle of the attribute maxAge cookie, the default is -1, that is, the browser is closed, and the cookie is invalid. The unit is ??, greater than zero, even if the cookie is closed, the cookie will still take effect. Attribute version int ASSIC value, according to RFC standard. RFC files are plain ASCII text file format RFC https://zh.wikipedia.org/wiki/RFC#RFC.E6.96.87.E4.BB.B6.E7.9A.84.E6.9E.B6.E6.A7 The .8B attribute path is no longer blind, and the source code description is attached.
* Specifies a path for the cookie
* to which the client should return the cookie.
*
* <p>The cookie is visible to all the pages in the directory
* you specify, and all the pages in that directory's subdirectories.
* A cookie's path must include the servlet that set the cookie,
* for example, <i>/catalog</i>, which makes the cookie
* visible to all directories on the server under <i>/catalog</i>.
*
* <p>Consult RFC 2109 (available on the Internet) for more
* information on setting path names for cookies.
The last attribute domain
reference document: http://blog.csdn.net/alexxu1988/article/details/47805205
* Specifies the domain within which this cookie should be presented.
*
* <p>The form of the domain name is specified by RFC 2109. A domain
* name begins with a dot (<code>.foo.com</code>) and means that
* the cookie is visible to servers in a specified Domain Name System
* (DNS) zone (for example, <code>www.foo.com</code>, but not
* <code>a.b.foo.com</code>). By default, cookies are only returned
* to the server that sent them.
Domain has more knowledge points.
The last point is that
cookies are insecure
cookies that can be tampered with and simulated. Because it is on the client side, I simulated the cookie of site A locally before, and this cookie can be directly used by the real site A. Then why use cookies. It's convenient.
It is recommended that the information stored in the cookie is not sensitive information, and things like passwords should not be considered in the cookie. The stored token should also be checked in the background. The technical threshold of cookie attack is very low.