I don't know if this will help, but I'll blurt it anyway.
I've been through a lot of hassle because we're doing applet-servlet
communication using the Java 1.2 plugin. I won't say anymore about this
because I already have flooded the listserv with my problems:(
Have you tried turning off cookie support on your servlet engine? I noticed
while going through Jason Hunter's snoop example in chapter 7 that URL
rewriting would not work unless I turned off cookie support for the servlet
engine. Specifically, if I wanted to see the format used by the servlet
engine, I used response.encodeUrl(req.getRequestURI()) and this ONLY showed
me something like /somepath;sesessionid=958234966546157650 after disabling
cookie support. With cookie support on, the ;sesessionid=1234980134091 was
missing.
I saw this behavior with both JRun and ServletExec.
Dave Godbey
> -----Original Message-----
> From: Boemio, Neil (CAP, FGI) [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, May 13, 2000 12:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: URL Rewriting & multipart/form-data
>
> JRun 2.3.3 is using: /somepath?sessionid=958234966546157650
>
> So I guess that is the problem and I'm screwed.
>
> I didn't know about the format: /somepath;sessionid=958234966546157650
>
> I really don't want to risk going to 3.0 yet .... so perhaps a higher
> version of 2.x fixes this? Does anyone know?
>
> Nic ... about your other suggestion .... I'm a little confused.
> First, here is what the JSP page does. It handles both the display of the
> page and the submission of the page. So the ACTION in the form simply
> calls
> the same page again (URL encoded with the correct session id). When the
> page receives a POST request, I parse out the parameters. When I check
> the
> session id before (and after) parsing the parameters, it's still not the
> correct one. So it seems that JRun is ignoring the session id in the
> ACTION
> parameter of the FORM tag.
>
> I'm not sure why your suggestion to try a request.getSession() after the
> parse would work, since it looks like JRun already has the session id
> before
> this (the wrong one, unfortunately). I did try it and it had no effect.
>
>
> -----Original Message-----
> From: Nic Ferrier [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 12, 2000 7:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: URL Rewriting & multipart/form-data
>
>
> >>> "Boemio, Neil (CAP, FGI)" <[EMAIL PROTECTED]> 12-May-00
> 10:53:31 PM >>>
>
> >When the form is submitted I do NOT get the correct session id.
> >That is the problem.
> >I'm using JRun 2.3.3 build 153
>
> As I said before the problem may be that the container cannot provide
> the session id if you parse the POST data yourself.
>
> This would most probably occur if the container used a parameter for
> the session id, eg:
>
> /somepath?jsessionid=SESH
>
> Containers are *supposed* to use the extension path, eg:
>
> /somepath;jsessionid=SESH
>
> You can obviously tell which is being used when you see the encoded
> page.
>
> I can't remember how JRUN 2.3.3 does it. I'm fairly sure that JRUN
> 3.0 (in beta now) does it properly though.
>
>
> The trouble is, if your container doesn't implement this properly
> there is nothing you can do because there is no way to ask for a
> session by it's id.
>
> One last thing to try if the session id is passed via a parameter -
> ensure that you call request.getSession() after the parse since this
> will give the container the opportunity at least to find the sesh id
> (but I guess you probably worked that out).
>
>
> If you're session *is* encoded by extension path then I can't see why
> it's not working - you'll have to submit your code.
>
>
>
> Nic Ferrier
>
> __________________________________________________________________________
> _
> 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
