Re: errata for cookie spec

On Fri, 7 Feb 1997, Jeremey Barrett wrote:

> 
> The only thing we're talking about is forcing user-agents to by default
> _not_ send cookies to domains which would be excluded from receiving
> them by the normal cookie/domain rules as applied to the _enclosing_
> document. i.e. ad.doubleclick.net can't get or set a cookie from an
> <img> embedded in a web page on a different site.
> 

Right. Is there some way to differentiate the REFERER of an inline image,
Java Applet, JavaScript routine, etc. from the REFERER of an HTML page, 
i.e. the place you just followed a link from. Do we want to require user 
agents to figure this out and block sending cookies to a domain that 
doesn't match the parent?

I append a couple of scenarios (apologies to anyone reading this on a 
palmtop or ham radio link ...). The first seems clearcut to me - the 
user agent does not store the cookie from domain B because it appears
inside a page from domain A .
The second, I'm not so sure about. Blocking cookies sent to
domain C because they are inside a frame from domain A will break C's 
legitimate shopping application. In this example, it is less likely that
C's page would be included in many frames than the advertisement banner
in the first one. And then there's Java banners, concealed JavaScript, 
etc.

Thoughts?

On another note, I'd like to see some stronger wording to discourage the 
indiscriminate use of cookies with a path of "/", which prevents entire 
sites from being cacheable and sabotages international cache peering 
efforts. Using a cookie on an in-domain inline image or frame is one way 
to register a user on a homepage without resorting to this. Alternatively
one could put a cookie on "/index.html". I'm glad that some effort has 
been made in the spec. to consider cacheing (though I must confess to 
being as yet confused by the wealth of control headers in HTTP 1.1).

http://vancouver-webpages.com/CacheNow/ - campaign for cache awareness

Andrew Daviel
andrew@vancouver-webpages.com