https://issues.apache.org/bugzilla/show_bug.cgi?id=49158
davidconnard <david.conn...@staff.rsvp.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #7 from davidconnard <david.conn...@staff.rsvp.com.au> 2010-07-20
10:14:30 EDT ---
Filip,
Your change doesn't actually do exactly what you think it does.
Your code - below - Response.java, line 992:
for (int i = 0; i < n; i++) {
if (headers.getName(i).toString().equals(headername)) {
if (headers.getValue(i).toString().startsWith(startsWith)) {
--> headers.setValue(sb.toString());
set = true;
}
}
}
Yes, setValue(contents) appears to be a logical call... however, that call is
actually setValue(name), and the returned contents are meant to be the
reference to the header (to which you can then add the value).
The result of that call is to add a header named, say:
JSESSIONID=54EDEDA814975EB485C2D9D660346717; Domain=.domain.com; Path=/
This doesn't actually appear to result in any additional response header
(presumably because the format was invalid, or the value was never set), and it
doesn't change the value of the existing Set-Cookie header. The following code
appears to work fine instead:
for (int i = 0; i < n; i++) {
if (headers.getName(i).toString().equals(headername)) {
if (headers.getValue(i).toString().startsWith(startsWith)) {
--> headers.getValue(i).setString(sb.toString());
set = true;
}
}
}
Note that you could probably optimise this (and avoid the set=true / later
addHeader() call by calling instead:
headers.setValue(name).setString(sb.toString())
This is proving to be critical to us (we manually invalidate sessions first
time around when we haven't seen them before - to guard against sessions being
presented from search engines), and we currently end up in an invalidation loop
as the second JSESSIONID is never actually presented back to the browser.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
