Please shed some light on my query regarding the use HttpClient in Applets.
Currently we are using Suns' HttpUrlConnection for connecting to our servlet which is behind the Single sign on. So in a sense, our every request from applet,
contains the cookie, for the SSO agent to be authenticated and passed to the servlet. My understanding is, that this cookie maintenance is performed by the java-plugin on the user machine with every request to the servlet and the HttpURLConnection combination.
But every now and then we receive the Invalid Stream header exception, on client machines, which is very random, and we think its coming from the SSO agent authenticating the request. This was not even caused with the long user inactivity, it happens even when user hits the servlet even for first time, and the SSO session is just created.
I was reading about HttpUrlConnection api, and the general opinion is, it is sometimes buggy with the browser api calls.
So, i wanted to know does moving on to HttpClient, mitigates this problem, or will we be facing the same random invalid stream headers.
If i want to do a POC using HttpClient, i was wondering how to do i maintain the SSO cookie, on my every request to servlet. Since in case of the HttpUrlConnection it was automatically taken care of by the java-plugin.
It's impossible to say whether HttpClient will or won't exhibit this problem, because we don't know what's causing it. There may be a bug in the HttpUrlConnection class (which HttpClient wouldn't have), or there may be a bug in the underlying Socket class (which HttpClient would have as well), or the problem may be with the network connection (in which case it doesn't matter what client is used), or the application code on top of the HTTP connection may be buggy.
HttpClient fully supports cookies, so I wouldn't think that that would be a problem.
Thank you for the reply.
Yes i totally agree with you on the fact of where the actual problem can be.
but just so that if i can prove its not the HttpUrlConnection, which is causing this problem. How can i implement the same
functionality with use of HTTpClient.
Right now my code looks like :
Here the SSO cookie is manage by the java-plugin, am just not sure how do i get the SSO authetication with the use of
HttpClient handles cookies transparently, there should be no need to do anything in code. (Actually, I'm not sure if cookie support is turned on by default - check the javadocs, there's a method named something "turnOnCookies" or some such). There are also methods to check which cookies you got after the response is received.
What does it mean to "have my servlet SSO protected" - how does anything change with respect to that? What does the documentation of whatever SSO solution you're using say about programmatic access to protected resources?
What does it mean to "have my servlet SSO protected"
It meant, when i try to hit my servlet with a get request, i am first shown a SSO page to login my credentials and then only the get request passes through
to hit my servlet. This SSO policy is enabled on our App servers, where the rootcontext "/XXX" is SSO protected.
So if i servlet is "www.testporject.net/XXX/myservlet" i will be shown a SSO first
So when i change my rootContext to "/YYYY" i can hit my servlet without any SSO.
So my actual scenario is,
I login to server1 with SSO protection, access the Applet hosted inside JSP there, and this applet tries to make connections to my servlet on server2, which is SSO protected too, since till now my java-plugin used to take care of all the cookie handling and i can access my servlet with SSO authentication again, since at server1 i was already authenticated and java-plugin carries this info for server2 SSO agent.
But with HTTPClient, i am not able to send this authentication info across to it just restricts me at the SSO of server2.
Like I said, you need to investigate which cookies the SSO system sets if you use a browser, and then make sure that the same cookies are retained when you use HttpClient. Obviously, that must be done using the same instances of whatever objects HttpClient uses, so that the cookies are still there.