I have not tried manually to set the cookie. I will give your suggestion a
try.
Thanks,
Dave
> -----Original Message-----
> From: Thomas Hii [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 03, 2000 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Applet (plugin Java 1.2)-servlet and session tracking
>
> Hi,
>
> As I understand it, cookie information is being passed between browser
> and servlet in the header fields. Have you tried passing cookie to the
> servlet in the header field when calling servlet? This way you can make
> the applet act like browser. i.e.
>
> URL url = new URL("http://myhost/servlets/test");
> HttpURLConnection conn = (HttpURLConnection)transportURL.openConnection();
> conn.setRequestMethod("POST");
> conn.setRequestProperty("Cookie", cookie);
>
> Hope that helps.
>
> Thomas Hii
>
> "Godbey, David" wrote:
> >
> > Nic, Craig,
> > Thanks for your help, and Jason Hunter too for his fine book.
> >
> > I have a solution to my problem (a question too), and thought this may
> be of
> > interest to the others.
> > In a nutshell, the problem is that an applet running in a plugin (within
> > object and embed tags) is apparently totally divorced from the page that
> it
> > lives in. And the key relationship in a session tracking context is
> between
> > the web page and the servlet.
> >
> > The ramifications of this is that the cookie passed between the applet
> and
> > servlet is wrong, and so you will always get a new session, even on
> return
> > trips to the servelt. Hence no automatic session tracking via cookies.
> URL
> > rewriting apparently wouldn't work either. My solution was to stream the
> > session id, and use servletcontext to get the session given the id. The
> > problem with my solution is the reliance on deprecated methods and
> classes.
> >
> > Perhaps everyone knew this but me. But what I just discovered after
> > carefully implementing Hunter's "snoop" example, then transposing it to
> the
> > applet - servlet situation, is this: The servlet engine (ServletExec)
> > ignores URL rewriting if a cookie is present! Is this standard procedure
> for
> > servlet engines? And with the wrong cookie present...well, this is why
> URL
> > rewriting fails.
> >
> > Solution: turn off cookie support for the servlet container, and URL
> > rewriting works just fine for this situation. Fortunately this will work
> for
> > me because the web server I'm using is dedicated to my application, and
> I
> > can work around cookies. Obviously if a situation arose where I needed a
> > cookie, I'd be up the creek.
> >
> > Is there a way to force URL rewriting even if a cookie is present?
> > Thanks,
> > Dave Godbey
> >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 12, 2000 5:39 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: HttpSessionContext -
> > > NeednewmethodHttpServletRequest.getSession(String sessionId)
> > >
> > > "Godbey, David" wrote:
> > >
> > > > Craig,
> > > > Thanks for the info. I tried your suggestions, but its just not
> working.
> > > I'm
> > > > using Servlet Exec 2.2, and my applet is running in the JRE 1.2
> plugin.
> > > > Every round trip begets a NEW session. The URL rewriting as you
> outlined
> > > > below is also ignored by the servlet.
> > >
> > > I guess I wasn't clear enough ... in order for this to work, you have
> to
> > > use the
> > > same URL rewriting technique that your servlet engine does. The
> example I
> > > quoted used the Servlet API 2.2 syntax. You need to double check
> which
> > > servlet
> > > API version is being supported by ServletExec -- if it's not Servlet
> API
> > > 2.2 (I
> > > don't know, you'll need to ask them), you need to ask them how they do
> > > their
> > > rewriting (or just do some pages with encoding and see for yourself),
> then
> > > copy
> > > that style exactly.
> > >
> > > >
> > > > In my research, I've come up with these messages on this topic,
> > > addressing
> > > > both the API (cookie) issue and URL rewriting, both of which are
> > > reported
> > > > below to not work.
> > > >
> > > > http://forum2.java.sun.com/forum?14@@.ee8f661
> > > > http://forum2.java.sun.com/forum?14@@.ee75c72
> > > >
> > > > Everything works great if I stick to the <APPLET> tag and native
> JRE.
> > > But
> > > > <OBJECT> and <EMBED> give no connectivity between the web page and
> the
> > > > applet (apparently) with respect to the cookie. So every time the
> applet
> > > > hits the servlet, whoops, getSession gets a brand new id.
> > > >
> > >
> > > I'm by no means an applet guru (native or plugin), but it seems there
> are
> > > two
> > > aspects to making this whole thing work:
> > >
> > > * How do you tell the applet what the user's session ID is?
> > >
> > > * How does the applet include this session ID on the requests
> > > that it makes itself?
> > >
> > > On the first issue, my suggestion was to pass a parameter to the
> applet,
> > > as you
> > > generate the page containing it. This parameter would contain the
> session
> > > ID of
> > > the user's current session, which you acquired with:
> > >
> > > HttpSession session = request.getSession();
> > > String sessionId = session.getId();
> > >
> > > According to the HTML 4.0.1 spec at least, you can embed parameters
> inside
> > > an
> > > OBJECT element:
> > >
> > > <object classid="..." ...>
> > > <param name="sessionid" value="xxxxxxx">
> > > </object>
> > >
> > > which should (if my understanding is correct) show up as an applet
> > > initialization parameter on IE. The same approach should work with
> > > <applet> for
> > > native-JVM execution. For Netscape's "embed" tag, it looks like you
> can
> > > just
> > > include the session id as another attribute on the <embed> element
> itself.
> > >
> > > For the second issue, you need to make sure that you are encoding
> things
> > > (if
> > > using URL rewriting) or sending a cookie (if using cookies) EXACTLY
> the
> > > way that
> > > your servlet engine does it for regular pages. If you don't the
> servlet
> > > is not
> > > going to be able to tell what session you were requesting, so it gives
> you
> > > a new
> > > one each request. Check the details for your specific engine, for
> > > example, for
> > > what cookie name it uses for the session ID.
> > >
> > >
> > > >
> > > > Are you quite sure about what you've said relative to running
> applets in
> > > a
> > > > PLUGIN, not the native browser JRE? Is there a way to doctor the
> header
> > > of
> > > > an output stream to embed the session id? I see that the
> > > HttpServletRequest
> > > > has a method to extract fields from the header. Can I create a
> cookie in
> > > the
> > > > applet and insert it into the output stream? Say by
> setRequestProperty
> > > on
> > > > the URLConnection object?
> > >
> > > You can use URLConnection.setRequestProperty() to pass a cookie. The
> > > property
> > > name you're setting is "Cookie", and the value must conform to the
> cookie
> > > specification (RFC 2109). This sets the header in your outgoing
> request,
> > > so
> > > that the servlet engine will see the cookie when it reads the request.
> > >
> > > >
> > > > Thanks for your help.
> > > > Dave Godbey
> > >
> > > Craig
> > >
> > >
> __________________________________________________________________________
> > > _
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > > body
> > > of the message "signoff SERVLET-INTEREST".
> > >
> > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > Resources:
> http://java.sun.com/products/servlet/external-resources.html
> > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
> __________________________________________________________________________
> _
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> __________________________________________________________________________
> _
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
