Hi Jeremy, I'm sorry I don't have the time to dig into this. >From a quick glance, I'd say that the combination of different server names and relative redirects might have shaken you off the path. RFC 2616 doesn't allow relative redirect locations, but nobody seems to care. So when you evaluate a Location: header with a relative path, make sure you do that with the server to which the request was actually sent.
Since your workaround works, you should go with it. The request with the credentials establishes the session, and afterwards you can freely navigate. The redirect is just supposed to tell the browser which is the entry page after login. If you're reasonably sure that this page is not going to change, then you don't have to read it from the response. hope that helps, Roland Jeremy Whitlock <[EMAIL PROTECTED]> 09.09.2005 17:51 Please respond to "HttpClient User Discussion" To HttpClient User Discussion <[email protected]> cc Subject Re: POST Form Session Expired Roland, I actually took a slightly different approach. Based on my feedback from Live Headers: #request# POST http://profile1.bea.com/shared_services/login/login.do;SHARED_SERVICES_SESSION=Dh8yKynv3FncslMdvhpTVmR7Q3H7mVV1KX2tw9p2RL5xgmXdyCbg!-1169276618!1598972357 POST /shared_services/login/login.do;SHARED_SERVICES_SESSION=Dh8yKynv3FncslMdvhpTVmR7Q3H7mVV1KX2tw9p2RL5xgmXdyCbg!-1169276618!1598972357 headerPath=%2Fhomepage%2Fheader_eis.html&footerPath=%2Fhomepage%2Ffooter_eis.html&navbarPath=%2Fhomepage%2Fnavbar_eis.html&returnURL=%2Flwsetter&webappURL=http%3A%2F%2Fentry- prodtest.bea.com&contentURL=http%3A%2F%2Fentry.bea.com&callingApp=Dev2Dev&stylesheetPath=%2Fhomepage%2Ffonts.css&action=login&support_url=http%3A%2F%2Fwww.bea.com%2Fframework.jsp%3FCNT%3Dindex.htm%26FP%3D%2Fcontent%2Fservices%2Fcustomer_support%2Fcontacts%2F&support_url_text=Contact+the+BEA+Support+Team&%7BactionForm.username%7D=MYUSERNAME&%7BactionForm.password%7D=MYPASSWORD #request# GET http://entry-prodtest.bea.com//ss_client?action=login&returnURL=%2Flwsetter&ssReturnCode=0000 #redirect# GET //ss_client?action=login&returnURL=%2Flwsetter&ssReturnCode=0000 #request# GET http://entry-prodtest.bea.com/lwsetter #redirect# GET /lwsetter #request# GET https://www.projects.dev2dev.bea.com/servlets/StartPage #redirect# GET /servlets/StartPage #request# GET http://entry.bea.com/lwsetter?eisal=true&vdest=https://www.projects.dev2dev.bea.com/servlets/StartPage #redirect# GET /lwsetter?eisal=true&vdest= https://www.projects.dev2dev.bea.com/servlets/StartPage #request# GET https://www.projects.dev2dev.bea.com/servlets/StartPage #redirect# GET /servlets/StartPage #request# GET https://www.projects.dev2dev.bea.com/servlets/StartPage #redirect# GET /servlets/StartPage #request# GET https://www.projects.dev2dev.bea.com/branding/css/tigris.css #request# GET https://www.projects.dev2dev.bea.com/branding/css/inst.css #request# GET https://www.projects.dev2dev.bea.com/branding/css/print.css #request# GET https://www.projects.dev2dev.bea.com/branding/scripts/tigris.js #request# GET https://www.projects.dev2dev.bea.com/branding/css/styles.css #request# GET https://www.projects.dev2dev.bea.com/local/images/bullet_.gif GET /local/images/bullet_.gif #request# GET https://www.projects.dev2dev.bea.com/favicon.ico GET /favicon.ico I realized that after I posted my credentials to the server, line 2 of the output, I could simply just do a get on the /servlets/MyStartPage to get where I needed. This seems to work. :) Anyways, I tried catching the Status Code of 302 and redirecting as well but still end up with just a redirect page. I probably screwed that up. Based on the output of the Live Headers, would you be able to give me some insight as to how you would approach such a series of POST/GET requests to make my application more stable? Take care, Jeremy On 9/9/05, Jeremy Whitlock <[EMAIL PROTECTED]> wrote: > > Roland, > Thanks for the help. That was what I had gathered yesterday by reading the > spec but I wasn't sure how to handle it. I now have a better understand and > with your suggestion, I think I can get this to work. I'll keep you all > posted. Take care, Jeremy > > On 9/9/05, Roland Weber <[EMAIL PROTECTED]> wrote: > > > > Hi Jeremy, > > > > > If I turn on post redirects, the code doesn't run. > > > > It's not allowed to run, in compliance with RFC 2616, > > sections 10.3.2, 10.3.3 and 10.3.8: > > > > <quote> > > If the 30? status code is received in response to a request other > > than GET or HEAD, the user agent MUST NOT automatically redirect the > > request unless it can be confirmed by the user, since this might > > change the conditions under which the request was issued. > > </quote> > > > > But your application can simply check the response for a > > 301, 302 or 307 response code, then read the "Location:" > > response header, and generate a followup request. Either > > a POST or a GET, as appropriate. Probably a GET. > > > > hope that helps, > > Roland > > > > > It errors out. When they > > > are off, here is the content I get a page from BEA saying that the > > resource > > > has moved. The HTML is irrelevant so here is the debugging information > > > > from > > > the HttpClient logging: > > > > > > http://www.rafb.net/paste/results/kGUsCS28.html > > > > > > If I didn't log enough or logged the wrong things, let me know. Other > > than > > > that...if you see anything I can do differently to get around this > > hurdle I > > > would be greatly appreciative. Take care and thanks for your help thus > > far, > > > Jeremy > > > > > > On 9/8/05, Gustavo Hexsel < [EMAIL PROTECTED]> wrote: > > > > > > > > I know there is some limitation about POST redirects, which seems to > > be > > > > the case. But you are in the right path. Have you tried monitoring > > which > > > > intermediate steps happen after authentication (using Mozilla's > > tool)? > > You > > > > should probably disable followsRedirect, see what comes back, and > > create > > > > another POST step that mimicks that. I could take a look, but you'll > > > > have > > > > to send the relevant parts of the wire log (the headers that are > > comming > > > > back just before the "java.lang.IllegalArgumentException: Entity > > enclosing > > > > requests cannot be > > > > redirected without user intervention"). > > > > > > > > []s Gus > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Jeremy Whitlock [mailto: [EMAIL PROTECTED] > > > > Sent: September 8, 2005 5:26 PM > > > > To: HttpClient User Discussion > > > > Subject: Re: POST Form Session Expired > > > > > > > > > > > > Gustavo, > > > > I have already tried this before to get yet another error. But just > > to > > > > > > make > > > > sure I am doing what you are saying, here is my updated code: > > > > > > > > http://www.rafb.net/paste/results/1g6i0M37.html > > > > > > > > Upon running this, I get the following: > > > > > > > > Sep 8, 2005 5:21:44 PM > > > > org.apache.commons.httpclient.HttpMethodDirectorisRedirectNeeded > > > > INFO: Redirect requested but followRedirects is disabled > > > > > > > > I cannot do post.setFollowRedirects(true) because it then complains > > about: > > > > > > > > java.lang.IllegalArgumentException: Entity enclosing requests cannot > > be > > > > redirected without user intervention > > > > at > > > > > > > > > > > > org.apache.commons.httpclient.methods.EntityEnclosingMethod.setFollowRedirec > > > > ts > > > > (EntityEnclosingMethod.java:221) > > > > at com.jwhitlock.http.client.HttpClientTutorial.main ( > > > > HttpClientTutorial.java > > > > :192) > > > > Exception in thread "main" > > > > > > > > I've not found a working solution but I'm sure we can figure this > > out. > > > > > > Take > > > > care, Jeremy > > > > > > > > On 9/8/05, Gustavo Hexsel <[EMAIL PROTECTED]> wrote: > > > > > > > > > > About the POST problem, can you post that part of the wire log? > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gustavo Hexsel [mailto:[EMAIL PROTECTED] > > > > > Sent: September 8, 2005 4:53 PM > > > > > To: 'HttpClient User Discussion' > > > > > Subject: RE: POST Form Session Expired > > > > > > > > > > > > > > > Cookies. Reuse the HttpClient instance throughout the whole > > operation. > > > > > > > > > > -----Original Message----- > > > > > From: Jeremy Whitlock [mailto:[EMAIL PROTECTED] > > > > > Sent: September 8, 2005 4:48 PM > > > > > To: HttpClient-User > > > > > Subject: POST Form Session Expired > > > > > > > > > > > > > > > Hey all, > > > > > I am doing a GET on a login form, parsing the form for hidden > > input > > and > > > > > then > > > > > > > > > > creating a POST with NameValuePair objects corresponding to the > > hidden > > > > > input > > > > > > > > > > and the two form input fields. I seem to have a minor problem with > > > > my > > > > > approach as I always get a "Session Expired" from the server I'm > > logging > > > > > into. Can someone give me a pseudo flow of how this goes? Here is > > the > > > > > current code: > > > > > > > > > > http://www.rafb.net/paste/results/mnOMtY87.html > > > > > > > > > > Can someone see what I'm doing wrong? I have tried a minor spin on > > > > this > > > > > where instead of creating an HttpClient for each method I have a > > global > > > > > one > > > > > but then I get a problem with the POST not being able to redirect. > > > > Thanks, > > > > > Jeremy > > > > > -- > > > > > He who listens well, speaks well. > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > He who listens well, speaks well. > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > He who listens well, speaks well. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > He who listens well, speaks well. > -- He who listens well, speaks well. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
