Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED]
Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff >DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG >RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT ><http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21124>. >ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND >INSERTED IN THE BUG DATABASE. >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21124 >IE cookie handling breaks interaction between single user and multiple appservers > Summary: IE cookie handling breaks interaction between single > user and multiple appservers > Product: Tomcat 4 > Version: 4.0.6 Final > Platform: All > OS/Version: All > Status: NEW > Severity: Normal > Priority: Other > Component: Catalina > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] >IN GENERAL: >For any two domains, A and B, if B is a subdomain of A (e.g., B.A), and if two >different J2EE app servers are hosting those domains, the following will be >true, assuming that the two appservers create session cookies that are >identical except for the domain (note that a cookie consists of: name, domain, >path, expiration): >* If a user, running Internet Explorer, uses J2EE apps running on both >domains, causing a session to be established on both domains simultaneously, >the client accessing the application running in domain B will not be able to >access a session established in domain B. >This is due to the fact that IE orders cookies from least-specific to most- >specific WITH RESPECT TO DOMAIN in an HTTP request. ANY app server that looks >for the FIRST cookie named JSESSIONID will be susceptible to this problem. >EXAMPLE: >In our case, tomcat was serving up JSPs on "x.com", causing a J2EE servlet >session to be created when that page was loaded. Immediately after hitting >x.com, "w.x.com" was being loaded, which also caused a session to be created. >Both sessions were being identified by cookies set in the client browser. The >cookies both had an ID of JSESSIONID, with an identical path. The only >difference between the cookies was the domain (one was "x.com", and the other >was "w.x.com"). When interacting with the app on w.x.com, each request >included an HTTP header specifying client-side cookies. In that header, the >JSESSIONID created by x.com was ordered BEFORE the JSESSIONID created by >w.x.com. The appserver on domain w.x.com was consequently attempting to find >the session that had been created on x.com, and since it could not, was >creating a new session with each request. >Unfortunately, IE does NOT disobey the Cookie spec. The spec is ambiguous >about what to do in this scenario, and Microsoft (big surprise) just chose to >do things differently than everyone else. The spec (RFC 2109) says in section >4.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. *** Ordering with respect to other attributes (e.g., >Domain) is unspecified.*** " >I added the emphasis. I don't see a good solution to the problem, other than >removing the mandate in the servlet spec that says JSESSIONID must be used to >identify the cookie... >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
