Sending a Cookie

Cookies Are Sent By Browsers Not Read By Sites

We often hear of sites "reading" cookies as if the site has the ability to send a crawler through the ether to enter a computer and read the files that it reads there. This is not the case. The decision for a cookie to be seen by a site is made entirely by the browser. If the browser decides a site should get the cookie the browser sends the cookie to the site; there is nothing the site can do to either prompt this or stop this.

In any event it is obviously important that the site does in the end get the cookie, because a reminder wouldn't really be worth much unless it is given. Equally, storing cookies is of no use unless they are replayed to the server which issued them.

Like the Set-Cookie: header, the Cookie: header is another very simple statement and looks as follows:

Cookie: zip=90210

That is it. There is nothing else to it. It is an additional header, here constituting 17 bytes of data!

In the context of the other headers coming form a browser request it may look as follows

GET / HTTP/1.1
Host: www.moviephone.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100714 SUSE/3.5.11-0.1.1 Firefox/3.5.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: zip=90210

Again I will not go into the specifics of the other headers but to point out that, like the Cookie: header, they are all information sent from the browser to the server letting the server know how best to respond to the browser.

The actual decision to send a cookie or not is mostly made at the time the cookie is initially accepted by the browser (if it was accepted it will likely be replayed). But each new request will check both the expiry (has the cookie expired - don't send) and the path (is the request to a location on the server where this cookie is permitted).