Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 574BFE1D5 for ; Tue, 4 Dec 2012 14:29:00 +0000 (UTC) Received: (qmail 72271 invoked by uid 500); 4 Dec 2012 14:29:00 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 72202 invoked by uid 500); 4 Dec 2012 14:28:59 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 71388 invoked by uid 99); 4 Dec 2012 14:28:58 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2012 14:28:58 +0000 Date: Tue, 4 Dec 2012 14:28:58 +0000 (UTC) From: "Karl Wright (JIRA)" To: dev@hc.apache.org Message-ID: <1285352846.59021.1354631338751.JavaMail.jiratomcat@arcas> In-Reply-To: <780432049.51516.1354493878361.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (HTTPCLIENT-1267) There seems to be no way to get HttpClient to include cookies from a custom store MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HTTPCLIENT-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509766#comment-13509766 ] Karl Wright commented on HTTPCLIENT-1267: ----------------------------------------- Hi Oleg, I am sorry if you got the impression that I was blaming you in any way for the way cookies work in general. All I'm trying to do is explain what we'd hoped to do in our project, and how we have done it in the past. How we do it in the future is open to negotiation, although it would be good I think to make sure we understand one another first. So let's first go into where I think things stand. I understand that there are lots of different forms of cookies. I understand also that in order to pull information out of the cookie one needs to know what form it is. I also know that the allowable forms are determined by the kind of header used to set the cookie, e.g. Set-Cookie or Set-Cookie2. However, as far as ManifoldCF is concerned, none of that is actually important. All that ManifoldCF wants to do is record the cookie (in its original header form), and retransmit it later (using the right header and in its original form). Unfortunately, commons-httpclient did not permit this, because there was no way to get the header form back out of a cookie. So we created a database schema that included all the fields that commons-httpclient seemed to support, and picked the cookie apart and put it back together for transmission to the server. However, I stress again that all of that is unnecessary from ManifoldCF's perspective; all we ever wanted to do was save the cookie in its unaltered header form in the database. For httpcomponents httpclient, there are two options for ManifoldCF. One option is to keep trying to do what we have done in the past, and break the cookie up. If that approach is to work, we need to understand how to properly disassemble the cookie using httpcomponents httpclient constructs, and reassemble it. Currently I clearly don't understand how to do that reliably. The second option is to figure out how to get the header form of the cookie, which is what we wanted to do in the first place, and also how to restore a Cookie object from its header form. It sounds, however, like that may still not be an option in httpcomponents at this time. Another option, which you've suggested, is to use Java serialization - however, in my experience, serialized objects are not a good thing to be putting into a persistent database, because new versions of software will come along and make those objects not deserialize in a reasonable manner. So I don't think we can use that approach. I am open to your suggestions as to how best to proceed. > There seems to be no way to get HttpClient to include cookies from a custom store > --------------------------------------------------------------------------------- > > Key: HTTPCLIENT-1267 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1267 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpCookie > Affects Versions: 4.2.2 > Reporter: Karl Wright > > In the port of ManifoldCF from commons-httpclient to httpcomponents, we discovered a problem or maybe a design flaw with how cookies are handled. > What we're trying to do is to follow a certain series of html pages, and record the cookies after that is done, and use exactly those cookies for a subsequent series of pages. So I have code that looks something like this: > {code} > DefaultHttpClient httpClient = new DefaultHttpClient(); > ... > CookieStore cs = new BasicCookieStore(); > cs.addCookie(...); // for each saved cookie > httpClient.setCookieStore(cs); > HttpGet httpget = new HttpGet(...); > HttpResponse response = httpClient.execute(httpget); > Cookie[] cookiesToSave = httpClient.getCookieStore().getCookies(); > [save the cookies aside] > {code} > What happens when I do this against a page that sets a cookie, is I get a perfectly reasonable cookie, and save it. For the next page, the code to add the cookie to the custom store then seems to work fine as well. But when I watch what is transmitted for the request (via header logging) I see no Cookie header being sent, and indeed the cookie seems to be lost. > Similar logic was done with HttpState in commons-httpclient, and worked perfectly there against the same website. > I have not yet tried the HttpContext approach for implementing this - I may try that while awaiting an answer to this ticket, but the above seems like it ought to work, according to the documentation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org