"Forward Hui" <ForwardHui@discussions.microsoft.com> wrote in message
news:80DA72D1-B021-4C34-8B01-334F111F542D@microsoft.com...
> I try to use an application + web server (e.g. perl + apache) to set some
> domain cookie.
>
> In IE8 ,
> If Set-Cookie: abc=ABC; path=/; domain=.ust.hk , the client cannot send
> the
> cookie to server in next request.
> If Set-Cookie: abc=ABC; path=/; domain=erpapp1.ust.hk , the client CAN
> send
> the cookie to server in next request.
> If Set-Cookie: abc=ABC; path=/; , the client CAN send the cookie to server
> in next request.
>
> For ie7 and firefox,
> All 3 case, the client CAN send the cookie to server in next request.
>
> I don't think the problem exist in domain name like ".google.com".
>
> Does someone got the same problem in domain cookie like .foo.hk ?
IE apparently uses the pre-RFC Netscape draft for cookies, which can be
found here:
http://web.archive.org/web/200802051...okie_spec.html
According to this, .ust.hk is not a valid domain - there must be at least 2
periods, and I'm assuming that a leading period is not valid. So, when you
use .ust.hk, that is equivalent to ust.hk (as IE uses tail matching for
domains), and as .hk is not one of the seven special TLDs it will be treated
as invalid. erpapp1.ust.hk is valid, and so works.
Basically, the assumption in the original Netscape drafts was that all
country specific TLDs (ie not the 7 "special" TLDs) would be subdivided, and
that domains would be allocated from those subdivisions, so cookies should
not be allowed to be set for a 2nd level domain.
google.com is fine, for instance, because COM is one of the 7 original
special TLDs.
--
Dan
Linear Mode
