HTTP-Cookie
A cookie ( [ kʊki ]; American " biscuit" ), is a text information (in this case "server") places the visited website on the browser to the computer of the viewer ( "Client "). The cookie is either sent from the Web server to the browser or by a script (eg JavaScript) generated in the site. The client sends the cookie information in later, new visits to this page with each request back to the server.
The concept was originally developed by Netscape and specified in RFC 2109.
- 5.1 cookie by Netscape
- 5.2 cookie according to RFC 2109
- 5.3 cookie according to RFC 2965
- 5.4 cookie according to RFC 6265
- 5.5 How it works - an example
Applications
HTTP is a stateless protocol, so the page views are independent of each other for the web server. A Web application whose interaction continues with the user across multiple page requests must work with tricks in order to identify the subscriber across multiple requests can away. For this purpose, a unique session ID may be stored in a cookie by the server to recognize exactly this client in successive runs. For security reasons, more of a one-time token for each page view is used in electronic banking.
Online stores may use cookies to collect goods in virtual shopping baskets. Enables the customer to add items to the cart and continued to look around on the website, then buy the items together. The ID of the shopping cart or the user's session is stored in the cookie, the Item IDs are assigned to the cart or the user's session on the web server. It was only when ordering this information will be evaluated on the server side.
Thus (for example, in mobile networks) are not lost in web applications user actions and entries destined for the server crashes when connecting to the server, cookies can be used for temporary storage. When reconnection they are queried from the server. Web application recognizes the order in which the cookies were produced and labeled already processed cookies, or deletes the content. Because generated in this use may many cookies, which are deleted when the browser is the earliest, the memory of the browser cookie is restricted, the Web application precautions against a cookie - overflow must meet.
Operation
There are two possibilities for the transfer, assignment and evaluation of cookies by selecting the site:
The local cookies the same domain - not the other sites - can be read out, recycled and changed. For information about the local user activities can be incorporated, for example, by Javascript, which were incurred in the meeting without further contact server. With the next contact with the site they are also transferred there in the HTTP headers.
Cookie information is stored locally in the browser, usually in a cookie text file. In subsequent further accesses to the web server, the client browser is looking out all cookies from this domain that fit the Web server and the directory path of the current call. This cookie data are transmitted in the header of the HTTP access with, so the cookies may decline only at those Web server from which they originated once.
A cookie can contain any text, so you can save addition to the mere identification, any settings locally, but its length should not exceed 4 kilobytes ( 4.1024 bytes) in order to remain compatible with all browsers. The cookies are transmitted with every file transmitted, including image files or any other file type; this is especially true for embedded elements such as banners, which are integrated by servers other than the origin of a displayed HTML file. Thus, a single Web lead to several cookies that come from different servers and sent back to this again in each case.
Cookies are managed by the client. Thus, the client will decide whether, for example, a cookie is saved or deleted after the life desired by the web server. However, such information can be stored to produce, for example, statistics on the number of requests for web pages on the server.
Common browsers allow the user to manage cookies more or less set, eg:
- Do not accept cookies.
- Only cookies the server of the called side accept ( no cookies from servers like banner ads ).
- Users should check with each cookie. Here, then usually "allow" between ( left ), "Allow for this session " (which is always accepted, but after you close the browser ) and " reject " (not accept ) are selected, the selected item is stored.
These allow the browser manage actions such as:
- View data in the cookie.
- Individual or delete all cookies.
Finally, the user can change, delete or empty the contents of cookies.
If a cookie was accepted or rejected, the server application in other HTTP requests can be seen as the storage of cookies is not reported by the client.
Hazards
Tracking
The possibility of unambiguous detection can be abused. Cookies are used, among other things, to create user profiles on the browsing behavior of a user. An online store can link these data with the customer's name and send targeted advertising messages. However, the online store only follow the surfing behavior within its own website.
Servers that are not identical to the server of the called webpage can also set so-called third- party cookies (English for third-party cookies ) about with image files ( banners or web beacons ); these are also known as "tracking cookies " refers to (English for tracking ). Optionally, so the visit different sites are associated with a user. The result is a " cross-server " session. It can deduce the interests of the visitor and adjusted accordingly Sites ( "personalized" ) are. When ordering in a webshop about the accrued data of a specific person to be assigned.
Risk at public access points
In environments where multiple users share the same computer, such as in schools or Internet cafes, there is a danger that an even valid session cookie is used by the next user of the computer to continue the meeting of its predecessor. This can be prevented by always delete all cookies before closing the browser or an appropriate browser setting uses.
Allow or Block
A compromise between the advantages and disadvantages of cookies can be achieved by configuring their browser to that persistent cookies are not approved or only against inquiry, making it difficult about the creation of user profiles and session cookies are automatically allowed, for example, Webeinkäufe, passwords. In addition, most browsers allow you to selectively allow cookies for a particular domain or to block or delete automatically after surfing as it happens automatically when session cookies. Server strangers can handle cookies automatically reject, on which a third party, such as an affiliate the website 's own behavior could record across multiple servers.
Browser often offer the opportunity to functions over small add-on programs ( add- ons ) to retrofit. So it is possible for example in Firefox with a specific add-on to allow a click of a button websites to store cookies or even to manipulate the contents of the cookies themselves. Cookies This can generally disable and enable exceptionally and if the website does not function properly without cookies or you want to log on to an online service.
See also: Web Analytics
Construction
A cookie consists of a name and a value. In the definition of a cookie can or one or more attributes must be specified in addition. According to specification (Netscape, RFC 2109, RFC 2965 ), there are different requirements for name, value, and attributes of the cookie.
Cookie by Netscape
" Set-Cookie: " Name " =" Value * ( ";" attribute) " Cookie: " Name " =" Value * ( ";" name "=" value ) Name = value is a sequence of printable US -ASCII characters without semicolon, comma and white space characters. If one of these characters will appear in name or value, it must be % xx encoded with URL encoding.
The following attributes are defined in the specification of Netscape:
Cookie according to RFC 2109
The difference in the specification of RFC 2109 to which consists of Netscape in particular, that as the value may also contain values semicolons, commas and white space characters now, but this must be put into quotation marks. Name can not begin with a $, however, because they are used for the identification of attributes of cookies in HTTP requests.
" Set-Cookie: " Name " =" Value * ( ";" attribute) " Cookie: " " $ Version " " =" value 1 * ( ( ";" | ",") cookie) Cookie here is a cookie can also contain specified in the Set-Cookie and separated by a semicolon pairs of values for path and domain next to the name - value pair:
In addition, the Expire attribute was replaced by the max-age attribute, which indicates the validity now as opposed to Expire attribute value instead of a fixed time in seconds. The semantics of domain has been extended. New additions include the attributes Comment and version.
Cookie according to RFC 2965
Cookies according to RFC 2965 differ from those of Netscape's specification and RFC 2109 in particular the fact that the header field set- Cookie2 means instead of Set-Cookie.
"Set - Cookie2: " Name " =" Value * ( ";" attributes) " Cookie: " " $ Version " " =" value 1 * ( ( ";" | ",") cookie) In addition, there are also some additional attributes:
In addition to these attributes, there is the HttpOnly attribute to prevent access to cookies via JavaScript and is supported by almost all browsers. Older browsers may not necessarily support this. This extension was probably originally introduced by Microsoft in Internet Explorer 6. On the cookies that have the HttpOnly attribute, can not be accessed by most browsers via JavaScript. This represents a possible protection against XSS, unless the respective used browser support for this attribute ( this extension is not part of the available RFCs).
Although RFC 2109 was completely replaced by RFC 2965, most Web browsers and servers support nor the HTTP cookie specification according to RFC 2109th Also the Expires is not actually used in the standard is still supported. There are RFC 2965 support in most modern web browsers. However, there are also differences in the completeness of the support, especially concerning HttpOnly.
Cookie according to RFC 6265
RFC 6265 obsolete both specifications and recommends the implementation of the original Netscape cookie. The Cookie2 implementation is "deprecated " ( obsolete ) in there is hardly any support except in the Opera browser.
How it works - an example
Scenario: A website offers a search function that can remember the last entered search term, even if the user exits the browser in the meantime. This keyword can not be saved on the server, because the server to the visitor would have to be clearly identified, and that takes more than pure HTTP. Therefore, the last term given by the browser of the visitor is to be stored ( in a cookie ).
If the visitor the search function first calls (here with the search term " cookie construction " ), it sends the following request to the server:
GET / cgi / suche.py? Q = cookie HTTP/1.0 construction The server responds with the result and asks the browser by using the " Set-Cookie " field to remember the last keyword (according to RFC 2109 ):
HTTP/1.0 200 OK Set-Cookie: last search = " cookie construction "; expires = Tue, 29- Mar-2005 19:30:42 GMT; Max-age = 2592000; Path = / cgi / suche.py; Version = "1" (Normally all the properties of cookies in a single line for better readability is here, however, only one attribute per line.. ) The cookie has the following properties:
- User data ( last search ): The last keyword
- Expiration Date ( expires ): The cookie is sent along only for queries that happen before 29 March 2005.
- Maximum age ( max-age ): The cookie is sent along only in the following 30 days, later no more.
- Part of the page (Path): The cookie will only be sent to the search engine ( / cgi / suche.py ), since all other parts of the website will not need the information.
According to RFC 2965, the response from the server as shown above might look like this:
The server responds with the result and asks the browser by using the " Set- Cookie2 " field to remember the last keyword (according to RFC 2965 ):
HTTP/1.0 200 OK Set Cookie2: last search = " cookie construction "; Max-age = 2592000; Path = / cgi / suche.py; Version = "1"; Port = 101; CommentUrl = " http://example.org/docs/cookies/letzteSuche " browser Requirements
According to RFC 2965, a browser will support the following:
- It should be able to save a total of at least 300 cookies.
- There are at least 20 cookies per domain can be stored.
- A cookie can contain is at least 4096 bytes.
Some browsers can handle more and larger cookies, but this is not guaranteed. Conversely, however, keep also not all browsers on all requirements.