Closed
Bug 79851
Opened 24 years ago
Closed 23 years ago
Session information lost when Java Plugin applet loaded
Categories
(Core Graveyard :: Java: OJI, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: jheight, Assigned: edburns)
References
Details
(Whiteboard: [oji_working][HAVE_FIX], ptd+)
Attachments
(5 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Ok,
I have some source code that reproduces the problem. Although it is a java
servlet/java applet combination (I hope that this isnt a problem). That source
code is at the end of this bug.
The problem is that between a http get and a http post the session information
is lost when the http get returns html code to startup a java applet. This was
not the case in mozilla 0.8.1 and has only appeared in mozilla 0.9.
I tested the following code segment on the sources from the 8th May 2001.
Here is the output (from my servlet) that I see:
Starting tomcat. Check logs/tomcat.log for error messages
2001-05-10 08:18:45 - ContextManager: Adding context Ctx( /agile_inf )
2001-05-10 08:18:45 - ContextManager: Adding context Ctx( /moz_test )
2001-05-10 08:18:47 - PoolTcpConnector: Starting HttpConnectionHandler on 8080
2001-05-10 08:18:47 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007
doGet Session ID is efrep4nqv1
doGet Session ID is efrep4nqv1
doPost Session ID is 43xgf2nqx1
As you can see between the doGet and doPost the session is invalidated and a
new one is created. (They should remain the same).
Note: I have confirmed that a html form post does not exhibit the same
behaviour, that is the session ID remains the same.
Anyhow here is my test code for the servlet (applet follows later). I hope that
you wont have a problem getting a servlet container up and running and the
class files in the appropriate places:
All output goes to system out on both the server and the applet (plugin window)
package mozilla_session_bug;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpUtils;
import javax.servlet.ServletException;
import java.io.*;
public class Untitled1 extends HttpServlet {
public Untitled1() {
}
protected void doGet(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException,
java.io.IOException {
HttpSession session = req.getSession();
System.out.println("doGet Session ID is "+session.getId());
session.setAttribute("myattribute", "myString");
resp.setContentType("text/html");
PrintWriter out = new PrintWriter(resp.getOutputStream());
String myUrl = HttpUtils.getRequestURL(req).toString();
out.println("<html><body><form method=\"post\" action=\""+myUrl+"\">");
out.println("<input type=\"submit\" name=\"doPost\" value=\"Do Post\" />");
out.println("</form>");
out.println("<embed");
//out.println("codebase='mozilla_session_bug'");
out.println("code='mozilla_session_bug.UntitledApplet'");
out.println("align='baseline'");
out.println("type='application/x-java-applet;version=1.3'");
out.println("width='100%' url='"+myUrl+"'>");
out.println("<noembed>No support for Java 2 applets </noembed> </embed>");
out.println("</body></html>");
out.flush();
out.close();
}
protected void doPost(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException,
java.io.IOException {
HttpSession session = req.getSession();
System.out.println("doPost Session ID is "+session.getId());
resp.setContentType("text/html");
PrintWriter out = new PrintWriter(resp.getOutputStream());
Object value = session.getAttribute("myattribute");
if (value == null) {
out.println("Oiii! The session lost the correct value");
} else if (value.equals("myString")) {
out.println("<html><body><h1>Yes the session contained the correct
value</h1></body></html>");
} else {
out.println("<html><body><h1>No! the session did not contain the correct
value (Wanted myString got "+session.getAttribute("myAttribute")
+"</h1></body></html>");
}
out.flush();
out.close();
}
}
APPLET CODE:
package mozilla_session_bug;
import javax.swing.JApplet;
import java.io.*;
import java.net.*;
/**
* Title:
* Description:
* Copyright: Copyright (c) 2001
* Company:
* @author
* @version 1.0
*/
public class UntitledApplet extends JApplet {
public UntitledApplet() {
}
public void start() {
try {
System.out.println("Started ...");
String serverURL = getParameter("url");
URL url = new URL(getDocumentBase(), serverURL);
URLConnection connection = url.openConnection();
connection.setDoInput(true);
connection.setDoOutput(true);
connection.setUseCaches(false);
connection.setRequestProperty("Content-Type", "text/xml");
PrintWriter out = new PrintWriter(connection.getOutputStream());
out.println("POST!");
out.flush();
out.close();
BufferedReader in = new BufferedReader(new InputStreamReader
(connection.getInputStream()));
String line = null;
do {
line = in.readLine();
System.out.println(line);
} while (line != null);
in.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
Reporter, I've compiled the Servlet and the applet, but you need to supply the
HTML. In particular, what should be the value of the URL param?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I've discerned that the HTML should be like this:
<HTML>
<BODY>
<APPLET WIDTH="400" HEIGHT="400" CODEBASE="."
CODE="mozilla_session_bug.UntitledApplet">
<PARAM name="url" value="http://127.0.0.1:8080/servlet/Untitled1"></PARAM>
</APPLET>
</HTML>
But I only see that doPost is getting called.
Here's the java console output:
<HTML>
<BODY>
<APPLET WIDTH="400" HEIGHT="400" CODEBASE="."
CODE="mozilla_session_bug.UntitledApplet">
<PARAM name="url" value="http://127.0.0.1:8080/servlet/Untitled1"></PARAM>
</APPLET>
</HTML>
Applet Installation finished.
Started ...
Opening http://127.0.0.1:8080/servlet/Untitled1
Connecting http://127.0.0.1:8080/servlet/Untitled1 with no proxy
Server http://127.0.0.1:8080/servlet/Untitled1 requesting to set-cookie
with "jwssessionid=PIIAHOIAAAAABQEBMQBQAAA;Path=/"
Oiii! The session lost the correct value
null
I don't think my test environment is correctly configured, because the code
that does the session.setValue() never gets called.
Yes, Sorry.
The URL you should enter into the webbrowser depends how you have setup the
servlet container. I should have specified this earlier. Here is how i have it:
1) I created a web context named moz_bug in the servlet container. This was a
folder located under the webapps directory of tomcat.
2) Underneath the moz_bug directory I created a folder named
mozilla_session_bug and placed the compiled applet class in there.
3) Again, Underneath the moz_bug directory I created a WEB-
INF/classes/mozilla_session_bug directory and placed the servlet class in there.
3) I ran up tomcat and used the following URL:
http://localhost:8080/moz_bug/servlet/mozilla_session_bug.Untitled1
This should bring back a web page on the client with an applet and a button.
The button was only to confirm that mozilla worked for html posts. It doesnt
work now since as soon as the applet is loaded the session changes hence the
bug. Look at the server console for the print out of the session ID in the get
and posts.
Let me know if this is still confusing...
Jason
The session.setValue occurs on the servlet get. So the servlet get needs to be
called to firstly setup the session and finally return the html to display the
applet.
So there is no html file per-se on the client. This is returned from the server.
I'm using JavaWebServer, not TOMCAT. What is TOMCAT? Is that some APACHE
thing?
Is there a way to test this using JavaWebServer and a static HTML page?
Let me download JavaWebServer and i'll give your detailed instructions.
Reporter, I'm observing the bug with the Applet I just attached. Can you
please review it and tell me if you think it will accurately reproduce the bug
you're seeing? Thanks,
Ed
YES! That Applet (inconjunction with the servlet earlier) produces the effect
that I am seeing. You can see at the server end that the session ID changes.
Hmm why didnt I do it that easily to start with ;-)
Thanks
Jason
Assignee | ||
Comment 10•24 years ago
|
||
I believe this is a bug in the Java Plugin/JDK. I have filed Sun internal
bugtraq bug 4458973. I'm re-assigning this bug to Stanley.
Assignee: edburns → stanley.ho
Status: ASSIGNED → NEW
Assignee | ||
Comment 11•24 years ago
|
||
*** Bug 79424 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 80018 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 13•24 years ago
|
||
If this is a Sun JVM bug then why did the same JVM work on Mozilla 0.8.1 and
now not on Mozilla 0.9.
Surely this indicates that something in Mozilla has changed that has caused the
fault.
Since I cant see Suns internal bug, would it be possible to have a short
explaination of why it is a JVM bug and not a Mozilla bug.
Thanks
Jason
Comment 15•24 years ago
|
||
Try it with latest Mozilla build, and JPI does make the call to
nsICookieStorage::getCookie, but the browser is not returning the right info.
Since this is a browser side problem, reassign to Ed.
Assignee: stanley.ho → edburns
Assignee | ||
Comment 16•24 years ago
|
||
Thanks Stanley. I'll look into the getCookie path.
Status: NEW → ASSIGNED
Assignee | ||
Comment 17•24 years ago
|
||
Stanley, I think the problem really is in the Java Plugin side. Here's why.
The applet makes the first get request on the servlet:
debug: edburns: HttpClient.writeRequests:
sun.net.www.MessageHeader@3bd23f{GET /servlet/Untitled1 HTTP/1.1: null}
{User-Agent: Java1.3.1-rc1}{Host: 127.0.0.1:8080}{Accept: text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}{null: null}{null: null}
{null: null}
Here is the reply:
debug: edburns: HttpClient.parseHTTPHeader:
sun.net.www.MessageHeader@2799c{null: HTTP/1.1 200 OK}{Server:
JavaWebServer/2.0}{Set-Cookie: jwssessionid=2XF1RLAAAAAABQEBMQBQAAA;Path=/}
{Cache-Control: no-cache="set-cookie,set-cookie2"}{Expires: Thu, 01 Dec 1994
16:00:00 GMT}{Content-Type: text/html}{Connection: close}{Date: Mon, 04 Jun
2001 23:36:41 GMT}
Server http://127.0.0.1:8080/servlet/Untitled1 requesting to set-cookie
with "jwssessionid=2XF1RLAAAAAABQEBMQBQAAA;Path=/"
We see that Java notices that the server is setting a cookie.
However, on the following POST request, we don't see this cookie being sent:
debug: edburns: HttpClient.writeRequests:
sun.net.www.MessageHeader@18cb3d{POST /servlet/Untitled1 HTTP/1.1: null}
{Content-Type: text/xml}{User-Agent: Java1.3.1-rc1}{Host: 127.0.0.1:8080}
{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-
alive}{Content-length: 7}{null: null}
Thus the server replies with another, different, cookie:
debug: edburns: HttpClient.parseHTTPHeader:
sun.net.www.MessageHeader@2bc3f5{null: HTTP/1.1 200 OK}{Server:
JavaWebServer/2.0}{Set-Cookie: jwssessionid=2XG0IAIAAAAADQEBMQBQAAA;Path=/}
{Cache-Control: no-cache="set-cookie,set-cookie2"}{Expires: Thu, 01 Dec 1994
16:00:00 GMT}{Content-Type: text/html}{Connection: close}{Date: Mon, 04 Jun
2001 23:37:41 GMT}
Server http://127.0.0.1:8080/servlet/Untitled1 requesting to set-cookie
with "jwssessionid=2XG0IAIAAAAADQEBMQBQAAA;Path=/"
You mention that the java plugin calls the browser's GetCookie, and it returns
null. This is correct, because it never saw the set-cookie come back in the
because the java plugin issued the HTTP request in the first place. The
browser can't have cookies in its cookie store that are sent as the HTTP
response from a request originated in the plugin.
Re-assigning back to Stanley.
Assignee: edburns → stanley.ho
Status: ASSIGNED → NEW
Assignee | ||
Comment 18•24 years ago
|
||
I stand corrected, the plugin uses the browser's cookie store. Back to me.
Assignee: stanley.ho → edburns
Assignee | ||
Comment 19•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
Unfortunately, this bug fix requires changes in both the browser and the
plugin. That means the customer will have to wait a long time to receive the
fix due to the rift between the java plugin schedule and the browser's
schedule.
I've notified the Sun engineer of the necessary action to take on the plugin
side.
Whiteboard: [oji_working] → [oji_working][HAVE_FIX]
Comment 23•24 years ago
|
||
if inOutCookieSize == cookieStringLen, then inOutCookieBuffer would not be null
terminated... could this cause trouble? and, if not, then why are you bothering
to memset(0) the buffer?
Assignee | ||
Comment 24•24 years ago
|
||
inOutCookieSize is not necessarily == cookieStringLen. CookieStringLen is the
length of the cookie from the cookie store. If cookieStringLen >
inOutCookieSize, we return without writing to the buffer. In most cases,
inOutCookieSize > cookieStringLen. I just memset the buffer to 0 for good
measure. If you like I can simple set the inOutCookieBuffer[cookieStringLen]
= '\0'.
Ed
Comment 25•24 years ago
|
||
my point was that if the buffer size is equal to the length of the cookie
string, then there would be no room for the null terminator. can this ever
happen?
Assignee | ||
Comment 26•24 years ago
|
||
Darin, yes, that can happen. I will modify the comparison for size to be this:
if (NS_FAILED(rv) || (!cookieString) ||
(inOutCookieSize =< (cookieStringLen = PL_strlen(cookieString.get())))) {
return NS_ERROR_FAILURE;
}
This will ensure that a buffer of insufficient size is not written to.
With that can you give sr=
Assignee | ||
Comment 27•24 years ago
|
||
Comment 28•24 years ago
|
||
ok, but i still don't understand why the memset is necessary. you will
get the correct result by just using strcpy in place of memcpy.
- nsCRT::memset(inOutCookieBuffer, 0, inOutCookieSize);
- nsCRT::memcpy(inOutCookieBuffer, (void *) cookieString.get(),
- cookieStringLen);
+ nsCRT::strcpy(inOutCookieBuffer, cookieString.get());
also, wouldn't it be really bad if the inOutCookieBuffer were too small?
why isn't it dynamically allocated?
Comment 29•24 years ago
|
||
whoops, nsCRT::strcpy does not exist... PL_strcpy is what i should have wrote.
Reporter | ||
Comment 30•23 years ago
|
||
Bug 83625 specifies a bug that involved breakage of cookies that occurred
around the same time as I logged this bug.
Is that bug related to this one?
Assignee | ||
Comment 31•23 years ago
|
||
Comment 32•23 years ago
|
||
this 3rd patch looks a heck of a lot like the 2nd one ;-)
Assignee | ||
Comment 33•23 years ago
|
||
Comment 34•23 years ago
|
||
this line can be removed:
+ nsCRT::memset(inOutCookieBuffer, 0, inOutCookieSize);
Assignee | ||
Comment 35•23 years ago
|
||
If I remove that line do I have sr=darin?
Assignee | ||
Comment 36•23 years ago
|
||
*** Bug 86252 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
sr=darin (once you remove that redundant memset line)
Assignee | ||
Comment 38•23 years ago
|
||
*** Bug 85827 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 39•23 years ago
|
||
The fix for the java plugin side of this bug will go into jdk1.4. I'd like to
get this on the 0.9.2 branch for netscape 6.1.
Keywords: nsBranch
Assignee | ||
Comment 40•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 41•23 years ago
|
||
Ed,
Did this fix actually get on the 0.9.2 branch for inclusion into Netscape 6.1?
Comment 42•23 years ago
|
||
*** Bug 90037 has been marked as a duplicate of this bug. ***
Comment 43•23 years ago
|
||
I think this bug needs to be reopened. We should *not* have to wait for JDK 1.4
to fix it.
Fact: It worked in Mozilla prior to 0.9.x.
Fact: It works in IE 5.5 with JDK 1.2.2, 1.3.0, and 1.3.1.
So why can't it be made to work in Mozilla with JDK 1.3.1? Can't you go back to
how it used to be? Are you telling us that we can't use Mozilla to access
Tomcat servers? (Tomcat being Sun's reference implementataion for JSPs and
servlets!)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 44•23 years ago
|
||
Thad, in your opinion should this bug have worked with 0.8.1? Please let me
know as soon as possible and we'll try it out with 0.8.1.
Reporter | ||
Comment 45•23 years ago
|
||
I know for a fact that this bug was not present in M0.8.1. The original
comments at the top of this bug stated that it broke for the M0.9 release.
I can still use the exact same JDK with Mozilla 0.8.1 without problems, as soon
as I use > Mozilla 0.9 it fails.
I am with Thad on this one, I am unsure why we need to wait for JDK 1.4.
Comment 46•23 years ago
|
||
I'm with Jason and Thad on this one too (have you guys added your votes for
this bug?). I don't see how MSIE and Moz 0.8x worked with previous JDKs but not
Moz 0.9x? It doesn't make sense that there was a problem in the JDK itself if
it still works in MSIE?
Also, does anyone know if this fix made it onto the Netscape 6 branch? If not,
then this bug would force me (reluctantly) to recommend to my company that we
can no longer support Netscape 6. We would also have to mention to our entire
client base for our new application suite that we cannot support Netscape 6 as
a browser and only MSIE5+ will be supported.
This is not a decision I would like to make, but we simply cannot wait for
JDK1.4 or Netscape 6.2 (or whatever it is deened to be) for our customers. I am
now the sole champion for Mozilla/Netscape here and I am about to be crushed by
the MSIE crowd.
This is an important MAJOR bug if you can't use a servlet based solution for an
application. I certainly hope this fix gets into the next release of Netscape
6.
BTW: Ed, thanks for your work on this issue, it is appreciated.
Assignee | ||
Comment 47•23 years ago
|
||
It went in the trunk. I'm awaiting permission to put it in the branch. I'm
also going to test it with 0.8.1.
Assignee | ||
Comment 48•23 years ago
|
||
I just pulled and built 0.8.1 branch on winnt and I can't even run it. I see
lots of assertions:
###!!! ASSERTION: potential deadlock between CMonitor@26b6a30 and
nsServiceManagerImplMonitor@a95040: 'Error', file F:\P
rojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250
0[a924d0]: ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and
nsServiceManagerImplMonitor@a95040: 'Error',
file F:\Projects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250
###!!! ASSERTION: potential deadlock between Monitor@26afc50 and
nsServiceManagerImplMonitor@a95040: 'Error', file F:\Pr
ojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250
0[a924d0]: ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and
nsServiceManagerImplMonitor@a95040: 'Error',
file F:\Projects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250
###!!! ASSERTION: potential deadlock between Monitor@26afc50 and
nsServiceManagerImplMonitor@a95040: 'Error', file F:\Pr
ojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250
0[a924d0]: ###!!! ASSERTION: potential deadlock between Monitor@26afc50 and
nsServiceManagerImplMonitor@a95040: 'Error',
file F:\Projects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250
###!!! ASSERTION: potential deadlock between Monitor@26afc50 and
nsServiceManagerImplMonitor@a95040: 'Error', file F:\Pr
ojects\0_8_1_BRANCH\mozilla\xpcom\threads\nsAutoLock.cpp, line 250
And the browser never comes up. I made sure to make it so there were no
profiles on my machine.
I'd love to know why this worked with 0.8.1.
Status: REOPENED → ASSIGNED
Comment 49•23 years ago
|
||
Ed,
I just tested this with the installer binary from build 2001032319 and it works
perfectly on WinNT4. Perhaps if you grabbed that source and built it, you
could see what we are talking about. Or you could install that binary first to
see it working....then go to the source.
Assignee | ||
Comment 50•23 years ago
|
||
*** Bug 83647 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 51•23 years ago
|
||
For the record, this works with JDK1.3.1 and today's trunk on Linux. It
doesn't work on the branch. Can someone please tell me how to get something
checked in on the branch?
Comment 52•23 years ago
|
||
Ed,
To check into the branch, you need to pull the MOZILLA_0_9_2_BRANCH tag. All you
need is an r= and sr= for the patch and you must have a PDT+ in the status
whiteboard of the bug. If you need that for this bug, Chofmann may help or you
can send mail to pdt2@netscape.com
Assignee | ||
Comment 53•23 years ago
|
||
I just tested this with the stock JDK1.3.1 and today's trunk on winNT and it
worked. This is without the JDK1.4 modification.
I've asked pdt2@netscape.com for branch permission.
Comment 54•23 years ago
|
||
get it in on the branch. thanks
Whiteboard: [oji_working][HAVE_FIX] → [oji_working][HAVE_FIX], ptd+
Comment 55•23 years ago
|
||
Thanks for following up on this Ed.
The big question I still have is, "will this fix make it into the next PR
release of Netscape 6?". This is the build that _really_ needs this fix.
Otherwise, even the next version of Netscape 6 won't work with any pages
generated by servlet based servers (JSP, etc).
Comment 56•23 years ago
|
||
the answer to your question is yes, barring this patch doesn't
cause any regressions.
Assignee | ||
Comment 57•23 years ago
|
||
Fix checked in to the branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 58•23 years ago
|
||
*** Bug 87775 has been marked as a duplicate of this bug. ***
Comment 60•23 years ago
|
||
This bug's been fixed a while ago based on the reporter. Marking verified.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•