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
