Proper handling of stale connections
Hi there, I wanted to confirm that I'm handling stale connections appropriately, so any input is appreciated. I've got a test configuration where embedded Jetty is handling the HTTP requests, and I've turned off stale connection checks on the client side. I'm using httpcore-4.0.1 and httpclient-4.0-beta2. I know, the rc1 version of the client is available, but not via the Maven central repo. First, I'm assuming that when I try to reuse a stale connection, what I'll get is a SocketException. Not that I'm counting on this, but it's the behavior I see with my test setup. Second, I really only want to retry the request when I get an IOException. And that there's no point in retrying more than once. Thanks, -- Ken -- Ken Krugler +1 530-210-6378 - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Cookie BestMatchSpec differences between 4.0-b2 and 4.0-rc1
Great, thanks. I've just been looking at the code and was coming to a similar conclusion myself. If you're ever over in London and find yourself in need of a beer, make sure you let me know - I definitely owe you a few by now! Thanks again, Sam 2009/7/7 Oleg Kalnichevski > On Tue, Jul 07, 2009 at 10:45:26PM +0100, Sam Crawford wrote: > > Thanks Oleg, much appreciated. > > > > Is there any major reason I should not opt for BrowserCompatSpec as my > > default? (I can understand why you wouldn't want to, as a library > > developer). We're communicating with all manner of servers (Apache, IIS, > > Tomcat, WebLogic, JBOSS, Jetty, and more) of many different versions. > > > > Thanks again, > > > > Sam > > > > Probably not. > > Oleg > > > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
Re: Cookie BestMatchSpec differences between 4.0-b2 and 4.0-rc1
On Tue, Jul 07, 2009 at 10:45:26PM +0100, Sam Crawford wrote: > Thanks Oleg, much appreciated. > > Is there any major reason I should not opt for BrowserCompatSpec as my > default? (I can understand why you wouldn't want to, as a library > developer). We're communicating with all manner of servers (Apache, IIS, > Tomcat, WebLogic, JBOSS, Jetty, and more) of many different versions. > > Thanks again, > > Sam > Probably not. Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Cookie BestMatchSpec differences between 4.0-b2 and 4.0-rc1
Thanks Oleg, much appreciated. Is there any major reason I should not opt for BrowserCompatSpec as my default? (I can understand why you wouldn't want to, as a library developer). We're communicating with all manner of servers (Apache, IIS, Tomcat, WebLogic, JBOSS, Jetty, and more) of many different versions. Thanks again, Sam 2009/7/7 Oleg Kalnichevski > Sam Crawford wrote: > >> Afternoon all, >> As mentioned in my previous mail, we've just moved to 4.0-rc1 from 4.0-b2. >> We've just had a report of a strange application issue, which appears to >> stem from a persistent cookie being rejected by HttpClient's >> BestMatchSpec. >> I've tried visiting the same page that sends the cookie in 4.0b2 and it >> accepts it just fine. >> >> Log from the error is shown below. >> >> I've tried using BrowserCompatSpec instead, and that seems to solve it, >> but >> I'm hesitant to move to that without running this issue past people here >> first. The expires attribute *looks* okay to me, but I'll gladly defer to >> your better cookie specification knowledge! >> >> Thanks, >> >> Sam >> >> >> >> [DEBUG] headers - << Set-Cookie: >> SESSf0c10f7f3c24e332bd057d860365d74c=kh1ic3aas0q476fjglvjoa58r2; >> expires=Thu, 30 Jul 2009 18:51:39 GMT; path=/; domain=. >> subdomain.company.com#] >> >> > Sam, > > Based on the properties of the cookie HttpClient picked up Netscape Draft > cookie spec, because only this specification permits commas in values that > are not enclosed with quotes. Prior to 4.0-rc1 BrowserCompatSpec was chosen, > which I felt was wrong. > > > The trouble is that according to the Netscape draft, the expiry date is > expected to be in the following format: > > 'EEE, dd-MMM- HH:mm:ss z' > > As a result the cookie gets rejected. > > There are two possibilities to work the problem around: > > (1) Override the date format using 'http.protocol.cookie-datepatterns' > parameter. This value will apply to all cookie specs. > > (2) Set the browser compatibility cookie spec for that particular host > using the 'http.protocol.cookie-policy' parameter on the HTTP request level. > > Hope this helps > > Oleg > > > [DEBUG] ResponseProcessCookies - Cookie accepted: "[version: 0][name: >> SESSf0c10f7f3c24e332bd057d860365d74c][value: >> kh1ic3aas0q476fjglvjoa58r2][domain: .subdomain.company.com][path: >> /][expiry: >> Thu Jul 30 19:51:39 BST 2009]". |#] >> >> [WARN] ResponseHandlerFactory - Received malformed cookie: >> org.apache.http.cookie.MalformedCookieException: Unable to parse expires >> attribute: Thu, 30 Jul 2009 18:51:39 GMT >> >>at >> >> org.apache.http.impl.cookie.BasicExpiresHandler.parse(BasicExpiresHandler.java:67) >> >>at >> org.apache.http.impl.cookie.CookieSpecBase.parse(CookieSpecBase.java:94) >> >>at >> >> org.apache.http.impl.cookie.NetscapeDraftSpec.parse(NetscapeDraftSpec.java:143) >> >>at >> org.apache.http.impl.cookie.BestMatchSpec.parse(BestMatchSpec.java:130) >> >>... >> >>at >> >> com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) >> >>at >> >> com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) >> >>at >> com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) >> >>at >> >> com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) >> >> |#] >> >> > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
Re: QUESTION ABOUT COOKIES
Joan Balagueró Valls wrote:
Hello,
Here the attach with the trace. It's a post request from my local app to my
servlet.
In all tests I've always used:
bcc.setVersion(1);
bcc.setAttribute(ClientCookie.VERSION_ATTR, "1");
Thanks,
Joan.
Joan,
I am afraid the attachment got stripped away. Post it inline.
Oleg
-Mensaje original-
De: Oleg Kalnichevski [mailto:ol...@apache.org]
Enviado el: martes, 07 de julio de 2009 17:18
Para: HttpClient User Discussion
Asunto: Re: QUESTION ABOUT COOKIES
On Tue, Jul 07, 2009 at 05:04:59PM +0200, Joan Balaguer? Valls wrote:
Hello Oleg,
Thanks, after some tests this is exactly what it happens.
When I send this cookie to my servlet, I receive all its data correctly
except the "max-age" attribute, which is always -1.
I'm trying to set MAX_AGE with your API, and I'm getting crazy...
I've tried "stdCookie.setExpiryDate(new
java.util.Date(System.currentTimeMillis() + 6)); // Expires after 60
seconds
But my servlet gets -1 (when I get cookies from HttpServletRequest with
request.getCookies()).
I supposed that I had to set the same value for MAX_AGE attribute. Then I
tried:
stdCookie.setExpiryDate(new java.util.Date(System.currentTimeMillis() +
6));
stdCookie.setAttribute(ClientCookie.MAX_AGE_ATTR, "60"); // 60 seconds
But my servlet still receives -1 in MAX_AGE.
Finally, I'm trying to set the "ClientCookie.EXPIRES_ATTR" with the value
of
java.util.Date(System.currentTimeMillis() + 6)), but the value passed
to
setAttribute is expected to be a String, and I have a java.util.Date. How
can I make this conversion?
Thanks in advance,
Post a wire log of the session:
http://hc.apache.org/httpcomponents-client/logging.html
Also, try setting cookie version to version 1 to force the use of a RFC
compliant cookie spec and see if that makes any difference.
Oleg
Joan.
-Mensaje original-
De: Oleg Kalnichevski [mailto:ol...@apache.org]
Enviado el: martes, 07 de julio de 2009 16:18
Para: HttpClient User Discussion
Asunto: Re: QUESTION ABOUT COOKIES
On Mon, Jul 06, 2009 at 08:14:48PM +0200, Joan Balaguer? Valls wrote:
Hello Oleg,
I?m trying to send cookies to a servlet with a simple app. Following the
tutorial:
HttpContext localContext = new BasicHttpContext();
CookieStore cookieStore = new BasicCookieStore();
BasicClientCookie stdCookie = new BasicClientCookie("name", "value");
stdCookie.setVersion(1);
stdCookie.setDomain(".mycompany.com");
stdCookie.setPath("/");
stdCookie.setSecure(true);
// Set attributes EXACTLY as sent by the server
stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");
stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");
cookieStore.addCookie(stdCookie);
localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);
HttpEntity entity = objHttp.execute(objPost, localContext).getEntity();
This does not work (at least for me). To work, you need to add:
stdCookie.setAttribute(ClientCookie.PATH, "/");
If I forget any of the ?set? statement, or any of the ?setAttribute?
statement, it does not work.
The question is: Why have we to set twice the components of the
?BasicClientCookie?, the first using ?stdCookie.set? and the second
using
?stdCookie.setAttribute??
And should I set ?ClientCookie.SECURE_ATTR? and
?ClientCookie.MAX_AGE_ATTR?
?
Joan
This is because some cookies set domain / path / port attributes
explicitly,
while some do not, in which case values of those attributes are derived
from
the properties of the origin server.
Consider the following example:
Set-Cookie:
stuff="very important"; path="/"; domain="myhost.mydomain.com";
version=1
Set-Cookie:
stuff="very important"; version=1
These two cookies are obviously different but they essentially represent
the
same piece of state information if sent in response to a request for
"http://myhost.mydomain.com/index.html";
And the second part: when the servlet receives this cookie, it is resent
to
another servlet using the same sequence of operations. But debugging,
one
can see that the cookie is not added to the cookieStore (the sentence
?cookieStore.addCookie(stdCookie);? does not add anything to
?cookieStore?).
A cookie does not get added to the cookie store only if it has expired.
Hope this helps
Oleg
Can you help me?
Thanks in advance,
Joan.
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpcl
Re: Cookie BestMatchSpec differences between 4.0-b2 and 4.0-rc1
Sam Crawford wrote: Afternoon all, As mentioned in my previous mail, we've just moved to 4.0-rc1 from 4.0-b2. We've just had a report of a strange application issue, which appears to stem from a persistent cookie being rejected by HttpClient's BestMatchSpec. I've tried visiting the same page that sends the cookie in 4.0b2 and it accepts it just fine. Log from the error is shown below. I've tried using BrowserCompatSpec instead, and that seems to solve it, but I'm hesitant to move to that without running this issue past people here first. The expires attribute *looks* okay to me, but I'll gladly defer to your better cookie specification knowledge! Thanks, Sam [DEBUG] headers - << Set-Cookie: SESSf0c10f7f3c24e332bd057d860365d74c=kh1ic3aas0q476fjglvjoa58r2; expires=Thu, 30 Jul 2009 18:51:39 GMT; path=/; domain=. subdomain.company.com#] Sam, Based on the properties of the cookie HttpClient picked up Netscape Draft cookie spec, because only this specification permits commas in values that are not enclosed with quotes. Prior to 4.0-rc1 BrowserCompatSpec was chosen, which I felt was wrong. The trouble is that according to the Netscape draft, the expiry date is expected to be in the following format: 'EEE, dd-MMM- HH:mm:ss z' As a result the cookie gets rejected. There are two possibilities to work the problem around: (1) Override the date format using 'http.protocol.cookie-datepatterns' parameter. This value will apply to all cookie specs. (2) Set the browser compatibility cookie spec for that particular host using the 'http.protocol.cookie-policy' parameter on the HTTP request level. Hope this helps Oleg [DEBUG] ResponseProcessCookies - Cookie accepted: "[version: 0][name: SESSf0c10f7f3c24e332bd057d860365d74c][value: kh1ic3aas0q476fjglvjoa58r2][domain: .subdomain.company.com][path: /][expiry: Thu Jul 30 19:51:39 BST 2009]". |#] [WARN] ResponseHandlerFactory - Received malformed cookie: org.apache.http.cookie.MalformedCookieException: Unable to parse expires attribute: Thu, 30 Jul 2009 18:51:39 GMT at org.apache.http.impl.cookie.BasicExpiresHandler.parse(BasicExpiresHandler.java:67) at org.apache.http.impl.cookie.CookieSpecBase.parse(CookieSpecBase.java:94) at org.apache.http.impl.cookie.NetscapeDraftSpec.parse(NetscapeDraftSpec.java:143) at org.apache.http.impl.cookie.BestMatchSpec.parse(BestMatchSpec.java:130) ... at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) |#] - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: QUESTION ABOUT COOKIES
Hello,
Here the attach with the trace. It's a post request from my local app to my
servlet.
In all tests I've always used:
bcc.setVersion(1);
bcc.setAttribute(ClientCookie.VERSION_ATTR, "1");
Thanks,
Joan.
-Mensaje original-
De: Oleg Kalnichevski [mailto:ol...@apache.org]
Enviado el: martes, 07 de julio de 2009 17:18
Para: HttpClient User Discussion
Asunto: Re: QUESTION ABOUT COOKIES
On Tue, Jul 07, 2009 at 05:04:59PM +0200, Joan Balaguer? Valls wrote:
> Hello Oleg,
>
> Thanks, after some tests this is exactly what it happens.
>
> When I send this cookie to my servlet, I receive all its data correctly
> except the "max-age" attribute, which is always -1.
>
> I'm trying to set MAX_AGE with your API, and I'm getting crazy...
>
> I've tried "stdCookie.setExpiryDate(new
> java.util.Date(System.currentTimeMillis() + 6)); // Expires after 60
> seconds
>
> But my servlet gets -1 (when I get cookies from HttpServletRequest with
> request.getCookies()).
>
> I supposed that I had to set the same value for MAX_AGE attribute. Then I
> tried:
>
> stdCookie.setExpiryDate(new java.util.Date(System.currentTimeMillis() +
> 6));
> stdCookie.setAttribute(ClientCookie.MAX_AGE_ATTR, "60"); // 60 seconds
>
> But my servlet still receives -1 in MAX_AGE.
>
> Finally, I'm trying to set the "ClientCookie.EXPIRES_ATTR" with the value
of
> java.util.Date(System.currentTimeMillis() + 6)), but the value passed
to
> setAttribute is expected to be a String, and I have a java.util.Date. How
> can I make this conversion?
>
> Thanks in advance,
>
Post a wire log of the session:
http://hc.apache.org/httpcomponents-client/logging.html
Also, try setting cookie version to version 1 to force the use of a RFC
compliant cookie spec and see if that makes any difference.
Oleg
> Joan.
>
>
>
>
> -Mensaje original-
> De: Oleg Kalnichevski [mailto:ol...@apache.org]
> Enviado el: martes, 07 de julio de 2009 16:18
> Para: HttpClient User Discussion
> Asunto: Re: QUESTION ABOUT COOKIES
>
> On Mon, Jul 06, 2009 at 08:14:48PM +0200, Joan Balaguer? Valls wrote:
> > Hello Oleg,
> >
> >
> >
> > I?m trying to send cookies to a servlet with a simple app. Following the
> > tutorial:
> >
> >
> >
> > HttpContext localContext = new BasicHttpContext();
> >
> > CookieStore cookieStore = new BasicCookieStore();
> >
> >
> > BasicClientCookie stdCookie = new BasicClientCookie("name", "value");
> > stdCookie.setVersion(1);
> > stdCookie.setDomain(".mycompany.com");
> > stdCookie.setPath("/");
> > stdCookie.setSecure(true);
> >
> > // Set attributes EXACTLY as sent by the server
> > stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");
> > stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");
> >
> >
> >
> > cookieStore.addCookie(stdCookie);
> >
> > localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);
> >
> >
> >
> > HttpEntity entity = objHttp.execute(objPost, localContext).getEntity();
> >
> >
> >
> >
> >
> > This does not work (at least for me). To work, you need to add:
> >
> >
> >
> > stdCookie.setAttribute(ClientCookie.PATH, "/");
> >
> > If I forget any of the ?set? statement, or any of the ?setAttribute?
> > statement, it does not work.
> >
> >
> > The question is: Why have we to set twice the components of the
> > ?BasicClientCookie?, the first using ?stdCookie.set? and the second
using
> > ?stdCookie.setAttribute??
> >
> > And should I set ?ClientCookie.SECURE_ATTR? and
> ?ClientCookie.MAX_AGE_ATTR?
> > ?
> >
>
>
> Joan
>
> This is because some cookies set domain / path / port attributes
explicitly,
> while some do not, in which case values of those attributes are derived
from
> the properties of the origin server.
>
> Consider the following example:
>
> Set-Cookie:
> stuff="very important"; path="/"; domain="myhost.mydomain.com";
version=1
> Set-Cookie:
> stuff="very important"; version=1
>
> These two cookies are obviously different but they essentially represent
the
> same piece of state information if sent in response to a request for
> "http://myhost.mydomain.com/index.html";
>
>
> >
> > And the second part: when the servlet receives this cookie, it is resent
> to
> > another servlet using the same sequence of operations. But debugging,
one
> > can see that the cookie is not added to the cookieStore (the sentence
> > ?cookieStore.addCookie(stdCookie);? does not add anything to
> ?cookieStore?).
> >
>
> A cookie does not get added to the cookie store only if it has expired.
>
> Hope this helps
>
> Oleg
>
>
> > Can you help me?
> >
> >
> > Thanks in advance,
> >
> > Joan.
> >
> >
> >
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
>
> -
> To unsubscribe
Cookie BestMatchSpec differences between 4.0-b2 and 4.0-rc1
Afternoon all, As mentioned in my previous mail, we've just moved to 4.0-rc1 from 4.0-b2. We've just had a report of a strange application issue, which appears to stem from a persistent cookie being rejected by HttpClient's BestMatchSpec. I've tried visiting the same page that sends the cookie in 4.0b2 and it accepts it just fine. Log from the error is shown below. I've tried using BrowserCompatSpec instead, and that seems to solve it, but I'm hesitant to move to that without running this issue past people here first. The expires attribute *looks* okay to me, but I'll gladly defer to your better cookie specification knowledge! Thanks, Sam [DEBUG] headers - << Set-Cookie: SESSf0c10f7f3c24e332bd057d860365d74c=kh1ic3aas0q476fjglvjoa58r2; expires=Thu, 30 Jul 2009 18:51:39 GMT; path=/; domain=. subdomain.company.com#] [DEBUG] ResponseProcessCookies - Cookie accepted: "[version: 0][name: SESSf0c10f7f3c24e332bd057d860365d74c][value: kh1ic3aas0q476fjglvjoa58r2][domain: .subdomain.company.com][path: /][expiry: Thu Jul 30 19:51:39 BST 2009]". |#] [WARN] ResponseHandlerFactory - Received malformed cookie: org.apache.http.cookie.MalformedCookieException: Unable to parse expires attribute: Thu, 30 Jul 2009 18:51:39 GMT at org.apache.http.impl.cookie.BasicExpiresHandler.parse(BasicExpiresHandler.java:67) at org.apache.http.impl.cookie.CookieSpecBase.parse(CookieSpecBase.java:94) at org.apache.http.impl.cookie.NetscapeDraftSpec.parse(NetscapeDraftSpec.java:143) at org.apache.http.impl.cookie.BestMatchSpec.parse(BestMatchSpec.java:130) ... at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) |#]
Re: QUESTION ABOUT COOKIES
On Tue, Jul 07, 2009 at 05:04:59PM +0200, Joan Balaguer? Valls wrote:
> Hello Oleg,
>
> Thanks, after some tests this is exactly what it happens.
>
> When I send this cookie to my servlet, I receive all its data correctly
> except the "max-age" attribute, which is always -1.
>
> I'm trying to set MAX_AGE with your API, and I'm getting crazy...
>
> I've tried "stdCookie.setExpiryDate(new
> java.util.Date(System.currentTimeMillis() + 6)); // Expires after 60
> seconds
>
> But my servlet gets -1 (when I get cookies from HttpServletRequest with
> request.getCookies()).
>
> I supposed that I had to set the same value for MAX_AGE attribute. Then I
> tried:
>
> stdCookie.setExpiryDate(new java.util.Date(System.currentTimeMillis() +
> 6));
> stdCookie.setAttribute(ClientCookie.MAX_AGE_ATTR, "60"); // 60 seconds
>
> But my servlet still receives -1 in MAX_AGE.
>
> Finally, I'm trying to set the "ClientCookie.EXPIRES_ATTR" with the value of
> java.util.Date(System.currentTimeMillis() + 6)), but the value passed to
> setAttribute is expected to be a String, and I have a java.util.Date. How
> can I make this conversion?
>
> Thanks in advance,
>
Post a wire log of the session:
http://hc.apache.org/httpcomponents-client/logging.html
Also, try setting cookie version to version 1 to force the use of a RFC
compliant cookie spec and see if that makes any difference.
Oleg
> Joan.
>
>
>
>
> -Mensaje original-
> De: Oleg Kalnichevski [mailto:ol...@apache.org]
> Enviado el: martes, 07 de julio de 2009 16:18
> Para: HttpClient User Discussion
> Asunto: Re: QUESTION ABOUT COOKIES
>
> On Mon, Jul 06, 2009 at 08:14:48PM +0200, Joan Balaguer? Valls wrote:
> > Hello Oleg,
> >
> >
> >
> > I?m trying to send cookies to a servlet with a simple app. Following the
> > tutorial:
> >
> >
> >
> > HttpContext localContext = new BasicHttpContext();
> >
> > CookieStore cookieStore = new BasicCookieStore();
> >
> >
> > BasicClientCookie stdCookie = new BasicClientCookie("name", "value");
> > stdCookie.setVersion(1);
> > stdCookie.setDomain(".mycompany.com");
> > stdCookie.setPath("/");
> > stdCookie.setSecure(true);
> >
> > // Set attributes EXACTLY as sent by the server
> > stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");
> > stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");
> >
> >
> >
> > cookieStore.addCookie(stdCookie);
> >
> > localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);
> >
> >
> >
> > HttpEntity entity = objHttp.execute(objPost, localContext).getEntity();
> >
> >
> >
> >
> >
> > This does not work (at least for me). To work, you need to add:
> >
> >
> >
> > stdCookie.setAttribute(ClientCookie.PATH, "/");
> >
> > If I forget any of the ?set? statement, or any of the ?setAttribute?
> > statement, it does not work.
> >
> >
> > The question is: Why have we to set twice the components of the
> > ?BasicClientCookie?, the first using ?stdCookie.set? and the second using
> > ?stdCookie.setAttribute??
> >
> > And should I set ?ClientCookie.SECURE_ATTR? and
> ?ClientCookie.MAX_AGE_ATTR?
> > ?
> >
>
>
> Joan
>
> This is because some cookies set domain / path / port attributes explicitly,
> while some do not, in which case values of those attributes are derived from
> the properties of the origin server.
>
> Consider the following example:
>
> Set-Cookie:
> stuff="very important"; path="/"; domain="myhost.mydomain.com"; version=1
> Set-Cookie:
> stuff="very important"; version=1
>
> These two cookies are obviously different but they essentially represent the
> same piece of state information if sent in response to a request for
> "http://myhost.mydomain.com/index.html";
>
>
> >
> > And the second part: when the servlet receives this cookie, it is resent
> to
> > another servlet using the same sequence of operations. But debugging, one
> > can see that the cookie is not added to the cookieStore (the sentence
> > ?cookieStore.addCookie(stdCookie);? does not add anything to
> ?cookieStore?).
> >
>
> A cookie does not get added to the cookie store only if it has expired.
>
> Hope this helps
>
> Oleg
>
>
> > Can you help me?
> >
> >
> > Thanks in advance,
> >
> > Joan.
> >
> >
> >
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: QUESTION ABOUT COOKIES
Hello Oleg,
Thanks, after some tests this is exactly what it happens.
When I send this cookie to my servlet, I receive all its data correctly
except the "max-age" attribute, which is always -1.
I'm trying to set MAX_AGE with your API, and I'm getting crazy...
I've tried "stdCookie.setExpiryDate(new
java.util.Date(System.currentTimeMillis() + 6)); // Expires after 60
seconds
But my servlet gets -1 (when I get cookies from HttpServletRequest with
request.getCookies()).
I supposed that I had to set the same value for MAX_AGE attribute. Then I
tried:
stdCookie.setExpiryDate(new java.util.Date(System.currentTimeMillis() +
6));
stdCookie.setAttribute(ClientCookie.MAX_AGE_ATTR, "60"); // 60 seconds
But my servlet still receives -1 in MAX_AGE.
Finally, I'm trying to set the "ClientCookie.EXPIRES_ATTR" with the value of
java.util.Date(System.currentTimeMillis() + 6)), but the value passed to
setAttribute is expected to be a String, and I have a java.util.Date. How
can I make this conversion?
Thanks in advance,
Joan.
-Mensaje original-
De: Oleg Kalnichevski [mailto:ol...@apache.org]
Enviado el: martes, 07 de julio de 2009 16:18
Para: HttpClient User Discussion
Asunto: Re: QUESTION ABOUT COOKIES
On Mon, Jul 06, 2009 at 08:14:48PM +0200, Joan Balaguer? Valls wrote:
> Hello Oleg,
>
>
>
> I?m trying to send cookies to a servlet with a simple app. Following the
> tutorial:
>
>
>
> HttpContext localContext = new BasicHttpContext();
>
> CookieStore cookieStore = new BasicCookieStore();
>
>
> BasicClientCookie stdCookie = new BasicClientCookie("name", "value");
> stdCookie.setVersion(1);
> stdCookie.setDomain(".mycompany.com");
> stdCookie.setPath("/");
> stdCookie.setSecure(true);
>
> // Set attributes EXACTLY as sent by the server
> stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");
> stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");
>
>
>
> cookieStore.addCookie(stdCookie);
>
> localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);
>
>
>
> HttpEntity entity = objHttp.execute(objPost, localContext).getEntity();
>
>
>
>
>
> This does not work (at least for me). To work, you need to add:
>
>
>
> stdCookie.setAttribute(ClientCookie.PATH, "/");
>
> If I forget any of the ?set? statement, or any of the ?setAttribute?
> statement, it does not work.
>
>
> The question is: Why have we to set twice the components of the
> ?BasicClientCookie?, the first using ?stdCookie.set? and the second using
> ?stdCookie.setAttribute??
>
> And should I set ?ClientCookie.SECURE_ATTR? and
?ClientCookie.MAX_AGE_ATTR?
> ?
>
Joan
This is because some cookies set domain / path / port attributes explicitly,
while some do not, in which case values of those attributes are derived from
the properties of the origin server.
Consider the following example:
Set-Cookie:
stuff="very important"; path="/"; domain="myhost.mydomain.com"; version=1
Set-Cookie:
stuff="very important"; version=1
These two cookies are obviously different but they essentially represent the
same piece of state information if sent in response to a request for
"http://myhost.mydomain.com/index.html";
>
> And the second part: when the servlet receives this cookie, it is resent
to
> another servlet using the same sequence of operations. But debugging, one
> can see that the cookie is not added to the cookieStore (the sentence
> ?cookieStore.addCookie(stdCookie);? does not add anything to
?cookieStore?).
>
A cookie does not get added to the cookie store only if it has expired.
Hope this helps
Oleg
> Can you help me?
>
>
> Thanks in advance,
>
> Joan.
>
>
>
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: Behavioural difference between 4.0b2 and 4.0-rc1
Perfect, thanks very much. Just wanted to make sure it wasn't an unexpected last minute side-effect before the 4.0-final release. Thanks once again, Sam 2009/7/7 Oleg Kalnichevski > On Tue, Jul 07, 2009 at 09:58:11AM +0100, Sam Crawford wrote: > > Morning all, > > We upgraded our application to use HttpClient 4.0-RC1 last weekend and > > observed a change in behaviour from 4.0-beta2 that I wanted to make you > > aware of (it may well be by design, just want to check!). > > > > Firstly, I should say that there was a clear error in our code, meaning > that > > if the response code was non-2xx we would not read the entire response > > stream from the HttpClient properly. This would in turn mean that the > > connection was not released automatically and readded to the pool. This > is > > where the difference lies: > > > > 1. In 4.0-beta2 there appears to be some background collector that > forcibly > > closes connections that have ended up in this state (the log line reads > > "Connection garbage collected...") > > 2. In 4.0-RC1 there is no such collecting process taking place (which in > > turn led to the connections not being closed, resulting in the connection > > pool being exhausted). > > > > I've attached traces of the occurrence. The comparison was made by using > > precisely the same application code and just swapping between the > different > > httpclient JARs. > > > > Again, the problem was clearly mine with the handling of the response > > stream. However, there is clearly a difference between beta2 and RC1, and > I > > just wanted to make sure it was expected behaviour. > > > > Thanks, > > > > Sam > > Hi Sam, > > This is expected behaviour. Until recently HttpClient used some non-trivial > logic to detect leaked connections using weak references and garbage > collection. However we got report about a fairly nasty memory leak caused > by > that particular bit of code under some rather special circumstances [1]. > The > developer who contributed most of the new connection management code has > left > the project for good. The issue was discussed on the dev list and the > majority > of committers felt that the feature was too hacky to be 100% reliable and > the > decision was made to remove it completely. For details see the dev mail > archive > and HTTPCLIENT-841 > > Oleg > > > [1] https://issues.apache.org/jira/browse/HTTPCLIENT-841 > > > > > > - > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
Re: Behavioural difference between 4.0b2 and 4.0-rc1
On Tue, Jul 07, 2009 at 09:58:11AM +0100, Sam Crawford wrote: > Morning all, > We upgraded our application to use HttpClient 4.0-RC1 last weekend and > observed a change in behaviour from 4.0-beta2 that I wanted to make you > aware of (it may well be by design, just want to check!). > > Firstly, I should say that there was a clear error in our code, meaning that > if the response code was non-2xx we would not read the entire response > stream from the HttpClient properly. This would in turn mean that the > connection was not released automatically and readded to the pool. This is > where the difference lies: > > 1. In 4.0-beta2 there appears to be some background collector that forcibly > closes connections that have ended up in this state (the log line reads > "Connection garbage collected...") > 2. In 4.0-RC1 there is no such collecting process taking place (which in > turn led to the connections not being closed, resulting in the connection > pool being exhausted). > > I've attached traces of the occurrence. The comparison was made by using > precisely the same application code and just swapping between the different > httpclient JARs. > > Again, the problem was clearly mine with the handling of the response > stream. However, there is clearly a difference between beta2 and RC1, and I > just wanted to make sure it was expected behaviour. > > Thanks, > > Sam Hi Sam, This is expected behaviour. Until recently HttpClient used some non-trivial logic to detect leaked connections using weak references and garbage collection. However we got report about a fairly nasty memory leak caused by that particular bit of code under some rather special circumstances [1]. The developer who contributed most of the new connection management code has left the project for good. The issue was discussed on the dev list and the majority of committers felt that the feature was too hacky to be 100% reliable and the decision was made to remove it completely. For details see the dev mail archive and HTTPCLIENT-841 Oleg [1] https://issues.apache.org/jira/browse/HTTPCLIENT-841 > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: QUESTION ABOUT COOKIES
On Mon, Jul 06, 2009 at 08:14:48PM +0200, Joan Balaguer? Valls wrote:
> Hello Oleg,
>
>
>
> I?m trying to send cookies to a servlet with a simple app. Following the
> tutorial:
>
>
>
> HttpContext localContext = new BasicHttpContext();
>
> CookieStore cookieStore = new BasicCookieStore();
>
>
> BasicClientCookie stdCookie = new BasicClientCookie("name", "value");
> stdCookie.setVersion(1);
> stdCookie.setDomain(".mycompany.com");
> stdCookie.setPath("/");
> stdCookie.setSecure(true);
>
> // Set attributes EXACTLY as sent by the server
> stdCookie.setAttribute(ClientCookie.VERSION_ATTR, "1");
> stdCookie.setAttribute(ClientCookie.DOMAIN_ATTR, ".mycompany.com");
>
>
>
> cookieStore.addCookie(stdCookie);
>
> localContext.setAttribute(ClientContext.COOKIE_STORE, cookieStore);
>
>
>
> HttpEntity entity = objHttp.execute(objPost, localContext).getEntity();
>
>
>
>
>
> This does not work (at least for me). To work, you need to add:
>
>
>
> stdCookie.setAttribute(ClientCookie.PATH, "/");
>
> If I forget any of the ?set? statement, or any of the ?setAttribute?
> statement, it does not work.
>
>
> The question is: Why have we to set twice the components of the
> ?BasicClientCookie?, the first using ?stdCookie.set? and the second using
> ?stdCookie.setAttribute??
>
> And should I set ?ClientCookie.SECURE_ATTR? and ?ClientCookie.MAX_AGE_ATTR?
> ?
>
Joan
This is because some cookies set domain / path / port attributes explicitly,
while some do not, in which case values of those attributes are derived from
the properties of the origin server.
Consider the following example:
Set-Cookie:
stuff="very important"; path="/"; domain="myhost.mydomain.com"; version=1
Set-Cookie:
stuff="very important"; version=1
These two cookies are obviously different but they essentially represent the
same piece of state information if sent in response to a request for
"http://myhost.mydomain.com/index.html";
>
> And the second part: when the servlet receives this cookie, it is resent to
> another servlet using the same sequence of operations. But debugging, one
> can see that the cookie is not added to the cookieStore (the sentence
> ?cookieStore.addCookie(stdCookie);? does not add anything to ?cookieStore?).
>
A cookie does not get added to the cookie store only if it has expired.
Hope this helps
Oleg
> Can you help me?
>
>
> Thanks in advance,
>
> Joan.
>
>
>
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
Re: stateful httpclient call in servlet
On Mon, Jul 06, 2009 at 01:51:07AM -0700, zhang99 wrote:
>
>
>
> pseudo code
>
> service(..){
>
>
> //httpclient get http://www.facebook.com
>
>
> }
>
> the above is pseudo code for java servlet, when user call this servlet
> service(..) from browser repeatly
>
> for instance
> 1. call http://localhost:8080/callService?url=facebook.com/index.php
> 2. call http://localhost:8080/callService?url=facebook.com/editprofile.php
>
> can these subsequent request using the same "session" ?
>
> any example demo on this?
See section on HTTP state management:
http://wiki.apache.org/HttpComponents/HttpClientTutorial
Oleg
> --
> View this message in context:
> http://www.nabble.com/stateful-httpclient-call-in-servlet-tp24351881p24351881.html
> Sent from the HttpClient-User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
