Okuduğunuz aynı RFC2109’dan alıntı :
* Etki Alanı için istek ana bilgisayarından x.foo.com'dan bir Set-Cookie = .foo.com
kabul edildi.
Böylece
subdomain.example.combir çerez ayarlayabilirsiniz
.example.com. Çok uzak çok iyi.
Uygulanabilir çerez-değerlerinin seçilmesinde aşağıdaki kurallar geçerlidir
Kullanıcı aracısının sahip olduğu tüm çerezler arasında.
Alan Seçimi
Kaynak sunucunun tam nitelikli ana bilgisayar adı etki alanı eşleşmeli
Çerezin Domain niteliği
Peki, etki alanı eşleştirmemiz var mı?
* A, bir FQDN dizesidir ve N'nin boş olmayan bir isim olduğu NB formuna sahiptir.
dize, B, B biçimine sahiptir ve B ', bir FQDN dizesidir. (Yani, xycom
etki alanı .y.com ile eşleşiyor, ancak y.com ile eşleşmiyor.)
Ama şimdi tanımına göre
example.cometki alanı eşleşmez
.example.com. Ancak
www.example.com(veya etki alanındaki herhangi bir "boş olmayan isim"). Bu RFC, teoride teorik olarak RFC2965 tarafından kullanılmakta ve bu,
Set-Cookie2işlemlerdeki alanlar için öncü bir noktayı zorlamakla ilgili şeyleri dikte etmektedir.
Daha da önemlisi, @Tony tarafından belirtildiği gibi gerçek dünyadır. Gerçek kullanıcı aracısının ne yaptığını bir bakış için, bkz.
Firefox 3'ün nsCookieService.cpp
ve
Chrome'un cookie_monster.cc
Gerçek siteler ne yaptığını içine perspektifi için, birlikte oynamayı deneyin
wgetkullanarak
--save-cookies,
--load-cookiesve
--debugne olup bittiğini görmek için.
Aslında, çoğu sitenin
Set-Cookieeski RFC özelliklerinden "Host" değerlerine sahip bir kombinasyon kullandığını , dolaylı olarak bir öncü nokta olmadan ( twitter.com'un yaptığı gibi) veya Etki Alanı değerlerini (öncü bir nokta ile) ayarlayıp yeniden yönlendirmeyi kullandığını göreceksiniz. gibi bir sunucuya
www.example.com( google.com gibi).