In Java HttpClient feature list it says:
Automatic Cookie handling for reading
Set-Cookie: headers from the server
and sending them back out in a Cookie:
header when appropriate.
But I can't figure out how to use this feature. I just need to open a web page, let it set all the cookies, then refresh the same page with received cookies.
Thanks.
I kept getting errors back from the server saying my client didn't support cookies and I should turn them on. The following line stopped those errors. Hope this works for you.
httpClient.setCookieStore(new BasicCookieStore());
Related
I am trying to create a cookie with SetSecure as true. This is creating problem in save or update methods and systems redirect to error page/ throw 403 error. If I remove SetSecure then it's working fine.
Cookie ck= new Cookie("key",value);
ck.setsecure(true);
response.addCookie(ck);// HttpResponse
Q1) Is it okay to just set secure flag to true? Or do I have to take care of some more changes in my webapp?
Q2) I am using http to connect to my webapp. Is this SetSecure flag works with http protocol? Or it has to be Https?
Thanks in advance.
A cookie with the secure flag to true only means that the browser in the other side won't send it to the server if the connection is unencrypted (eg. in http protocol)."The purpose of the secure flag is to prevent cookies from being observed by unauthorized parties due to the transmission of a the cookie in clear text."
So in you're case, the cookie will never be sent back to the server after being created, that's why you are getting an error. If you really need to use this flag for whatever reason, you should use an https server.
Cookie
am new to android and cookie concept, plz guys help me how insert a some value device number,device version and phone model name in cookies and tat cookie send into an url.i saw lot of examples but i dont know exact part.. am in still in confusion.plz guys solve my problem.phone model,device name,os version into cookie,send cookie into an url.
Cookies are not send in the url, they are sent in the HTTP header.
What library are you using ? It should have a method for sending cookies in the request.
Probably what you really need is to make cookie visible to server so it will look like normal HTTP request from browser. Is that right?
Then you don't need to insert cookie in URL.
Cookie is a special content that is sent with request headers. It is normally not exposed to user.
So what you probably need is some Java library that will handle the HTTP protocol for you. Just google some, there are plenty of them for both Java EE and for Android. They will much simplify how you can deal with HTTP requests.
Also I am not really familiar with Android development but I reckon that framework itself should have ability to manage HTTP requests with no problem. Maybe some documentation lookup will help?
We are using IBM Websphere Application Server 6.1 and browser is Internet Explorer 8.
We have a java servlet which dynamically generates PDF and MS Word documents. On the first attempt some users are saying they are getting
"Internet Explorer was unable to open this site. The requested site is either unavailable or cannot be found. Please try again later."
As per Microsoft Support article id 323308
When you try to open a Microsoft Office document or a PDF document over HTTPS (SSL) IE fails with above error message.
This issue occurs if the server sends a "Cache-control:no-store" header or sends a "Cache-control:no-cache" header.
For IE8 Microsoft suggests to add registry entry on users Windows XP desktop. This is not very practical for us to do as we don't control our users desktops. This does not happen for IE9, Firefox, Chrome, etc.
As per PK20531 WAS 6.1 is adding Cache-Control: no-cache="set-cookie, set-cookie2" and Expires
HTTP headers when there is cookie being set in the response.
Note - We are not setting the cookie in the servlet. The cookie is set by single sign-on software.
On the first attempt when the single sign-on (LTPA) cookie is being set and WAS is adding HTTP headers which IE browser does not like.
Does Java servlet api provide a way to remove http headers? Is there a technique to use Filter api to remove http headers?
If you remove the Cache-Control header from the response, then you're not sending any instructions about caching and therefore the caching behavior would be unpredictable.
It would be better to set the header to something else, rather than remove it. Presumably you want to enable caching on the browser for your pages. So you could add these lines to your servlet to enable caching in the browser:
response.setHeader("Pragma", "cache");
response.setHeader("Cache-Control", "private, must-revalidate");
You could do this in a Filter too, because filters have access to the HTTP response object. But if you've written your own servlet then it's probably more efficient — and clearer — to do it in the servlet.
It's all controllable by you. If you don't put it there, there will be nothing to remove.
I want to create a small java application to copy some wiki content from one server to another. The API is based on the XML-RPC.
Basically I have three methods, login, getPage and putPage. I use Apache HttpClient 3.x and managed to use login to login successfully and getPage to get a page from the old wiki correctly.
Authentication is handled with cookies: I log into the new wiki and some cookies are set on the corresponding httpclient. The doku tells me that one of those cookies is used for authentification.
Then I execute putPage with another POST method on the same httpclient and the server responds with a authentication failure message.
The code sequence goes like this (very reduced):
HttpClient client = new HttpClient();
PostMethod postLogin = createNewPostMethod("login", "user", "pw");
client.executeMethod(postLogin);
// Now I'm logged in and the client definitly has stored the cookies
PostMethod postPutPage = createNewPostMethod("putPage", getPage());
client.executeMethod(postPutPage); // the server won't let me put the page
Should it work like that or do I have to add the cookies manually to the second post method and, if yes, how?
Edit / Solution
With the help of the answers to this question I was able to identify and solve the problem, which was outside of the usage of httpclient. At the end it was a configuration issue on the target wiki side. The answers here helped me to ask the right questions in another forum.
Cookies are handled by HTTPClient by default. You shouldn't have to do anything to have cookies work properly.
Source:
http://www.innovation.ch/java/HTTPClient/getting_started.html#cookies
Edit for Apache HTTP Client:
Apache HTTP Client behaves the same :-)
Here is the source:
http://hc.apache.org/httpclient-3.x/cookies.html
You can set manually cookies with HTTP Client but it will handle correctly cookies created during your connection.
HttpClient supports automatic management of cookies, including allowing the server to set cookies and automatically return them to the server when required. It is also possible to manually set cookies to be sent to the server.
Resources :
Apache HttpClient - cookies
I have historically used this when I wanted to accept cookies with HttpClient
postPutPage.getParams().setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY);
Can anybody explain the following:
The unique JSESSIONID generated by the
server for every client is exchanged
between the client and server using
Hidden form field
Thanks
What server technology is this? Technically, you could do some form of session tracking if a form was posted every request, but I've never seen someone attempt this. It isn't something in any Java EE API I've come across.
The Servlet specification only lists three session tracking mechanisms: HTTP cookies; SSL sessions; and URL rewriting.
This is not true. It's been exchanged as a cookie.
Cookies are specified in the HTTP request and response headers. To see it yourself, use some tool with which you can view those headers, such as for example Firebug or Firefox Web Developer Toolbar.
Maybe you confused it with the "view state" which some MVC frameworks indeed passes as a hidden input field.