Java Reference
In-Depth Information
entire subdomain, not just at the original server. For example, this request sets a user
cookie for the entire foo.example.com domain:
Set-Cookie: user=elharo;Domain=.foo.example.com
The browser will echo this cookie back not just to www.foo.example.com , but also to
lothar.foo.example.com , eliza.foo.example.com , enoch.foo.example.com , and any other
host somewhere in the foo.example.com domain. However, a server can only set cookies
for domains it immediately belongs to. www.foo.example.com cannot set a cookie for
www.oreilly.com , example.com , or .com , no matter how it sets the domain.
Websites work around this restriction by embedding an image or oth‐
er content hosted on one domain in a page hosted at a second do‐
main. The cookies set by the embedded content, not the page itself, are
called third-party cookies . Many users block all third-party cookies, and
some web browsers are starting to block them by default for privacy
reasons.
Cookies are also scoped by path, so they're returned for some directories on the server,
but not all. The default scope is the original URL and any subdirectories. For instance,
if a cookie is set for the URL http://www.cafeconleche.org/XOM/ , the cookie also applies
in http://www.cafeconleche.org/XOM/apidocs/ , but not in http://www.cafeconleche.org/
slides/ or http://www.cafeconleche.org/ . However, the default scope can be changed using
a Path attribute in the cookie. For example, this next response sends the browser a cookie
with the name “user” and the value “elharo” that applies only within the server's /restric‐
ted subtree, not on the rest of the site:
Set-Cookie: user=elharo; Path=/restricted
When requesting a document in the subtree /restricted from the same server, the client
echoes that cookie back. However, it does not use the cookie in other directories on the
site.
A cookie can include both a domain and a path. For instance, this cookie applies in
the /restricted path on any servers within the example.com domain:
Set-Cookie: user=elharo;Path=/restricted;Domain=.example.com
The order of the different cookie attributes doesn't matter, as long as they're all separated
by semicolons and the cookie's own name and value come first. However, this isn't true
when the client is sending the cookie back to the server. In this case, the path must
precede the domain, like so:
Cookie: user=elharo; Path=/restricted;Domain=.foo.example.com
A cookie can be set to expire at a certain point in time by setting the expires attribute
to a date in the form Wdy, DD-Mon-YYYY HH:MM:SS GMT. Weekday and month are
Search WWH ::




Custom Search