This will also affect session cookies from the same server, but with 
different paths.

e.g.

Given a request for http://example.com/path1, a "domain=.example.com; 
path=/" session cookie will over-write the correct "domain=.example.com; 
path=/path1" session cookie.

If the browser is compliant with the spec the more specific cookies are 
sent first and PHP prevent their overwriting by less specific cookies.

Perhaps you'd like more information rather than marking this as bogus.

What detailed info would you like?

No, thanks. Ilia's reply is quite clear.

I have confirmed this cookie collision while using Firefox and Safari. I 
believe they are compliant with the spec.

The more specific cookies are sent first and PHP does NOT appear to 
prevent over-writing by the later, less-specific cookies.

What detailed info would you like?

http://cvs.php.net/viewvc.cgi/php-src/main/php_variables.c?annotate=1.104.2.10.2.7#l204
/* According to rfc2965, more specific paths are listed above the less specific ones.
* we encounter a duplicate cookie name, we should skip it, since it is not possible
* to have the same (plain text) cookie name for the same path and we should not overwrite
* more specific cookies with the less specific ones.
*/

If your browser (whatever it is) does not comply with the standard, you should complain to your browser developers, not PHP.

Hi Tony, thanks for pointing at the source code reference. I am not 
familiar with PHP internals.

I'm using PHP 4.4.6 and it's version of main/php_varriables.c (lines 
201-209) does not (at first glance) appear to be analogous to the PHP 5 
version (lines 209-218).

Perhaps there is something in those lines that are the problem in PHP 4?

(I have checked Firefox 2, IE 7, and Safari 2 and the problem persists, 
so it can't be the browsers.)

The RFC mentions that order in regards to domain is unspecified which I think this bug is in regards to rather than the path issue.

Spec >>
   If multiple cookies satisfy the criteria above, they are ordered in
   the Cookie header such that those with more specific Path attributes
   precede those with less specific.  Ordering with respect to other
   attributes (e.g., Domain) is unspecified.

Does the reporter have an example of a browser which demonstrates the bug here?

Just tested this with 5.2.2-dev and I can't reproduce the issue.

By default PHP doesn't set a domain parameter for the session cookies, even when I did this the cookie for .example.com could be read by the host other.example.com, since other.example.com didn't set another session cookie I couldn't see an issue.

Can you provide an example of the HTTP header that is being sent? There is an extension for Firefox called Live HTTP Headers that will provide the information.

Scott, I hadn't realized that the cookie spec didn't specify the order 
with regards to the domain. Uh-oh.

My application (Drupal) specifies "/" as the path and also specifies a 
domain when setting the cookie (both for other.example.com and 
example.com). And the "Live HTTP Headers" plug-in reports both cookies 
are sent:

http://dev.albin.net/

GET / HTTP/1.1
Host: dev.albin.net
Cookie: PHPSESSID=fb4f595010d9cfbd8017dfc57eed6993; PHPSESSID 
=6cb4fca68cce1846cdccde82b151d5bb

HTTP/1.x 200 OK
Server: Apache/1.3.33 (Darwin) PHP/4.4.6 mod_perl/1.29
X-Powered-By: PHP/4.4.6
Content-Type: text/html; charset=utf-8

However, the fb4f5... cookie value is for .albin.net and the 6cb4... 
cookie value is for dev.albin.net.

The spirit of the cookie spec would suggest that the dev.albin.net 
should be sent first, but alas...

So this is a bug in the cookie spec. And not one in PHP or the web 
browser. Nuts.

The work-around for others in the situation is to set a unique 
cookie_name() for each installation of your PHP app.

I am already actively working with the Drupal (PHP-based CMS) 
community to get this work-around implemented.
http://drupal.org/node/56357

Thanks for your help, Scott! And Tony and Iliaa!