Our server infrastructure uses Tomcat 4.1 to host various web applications we make. Our web applications are fantastic and looks beautiful especially in Safari - too bad Safari has a bug that prevents us from using them.
Servlet engines uses session cookies to keep track of server side sessions. A servlet engine can have several web applications running at the same time - each with its own session. Each web application is bound under a URL path such as "/" maps to what Tomcat calls the ROOT application and "/publisher2" binds to a web application we've created.
Each such web application has its own session and its own session cookie deployed in the browser using the 'Path=something' feature of the cookie to keep them separate. E.g. the ROOT session gets Path=/ and the publisher2 session gets Path=/publisher2. When the browser presents the cookies back, it needs to present all cookies that matches the path your requesting. E.g. if we're requesting "/publisher2/index.jsp" the browser must present back both cookies since both "/publisher2" and "/" matches the URL requested.
The cookie spec (rfc2965) talks about a browser having several matching cookies section 3.3.4:
...
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.
...
Tomcat is very set on this part of the spec and in the above case when requesting "/publisher2/index.jsp" expects the "/publisher2" cookie to be presented first. However Safari breaks the spec and seems to have a random order.