Hi guys,
I see that you have often problems accessing different websites, with login
keeping sessions etc. For IE it works but not with the http-client.
I know NOW all these problems and they arise usually because of hidden
posted-session-id's, cookies, cookies which are sent in another format
Hi Tom,
I cannot access it also with my IE. Your sure you have no cookies in IE?
I mean there are lots of id's in the url, usually they're checked if they
fit to your cookies.
R.
-Original Message-
From: Steve Johnson [mailto:[EMAIL PROTECTED]
Sent: 22 September 2004 00:23
To: 'Commons
(Sorry, I sent it as HTML before)
Hi guys,
I see that you have often problems accessing different websites, with login
keeping sessions etc. For IE it works but not with the http-client.
I know NOW all these problems and they arise usually because of hidden
posted-session-id's, cookies, cookies
If you want to access an HTTPS page with proxomitron (you need version 4.5.1
!) , but seeing also the parameters you have to do the request like:
http://https..lb32.resources.hewitt.com/sg1dgp9/tbiappt300/TbiaAuthPage?Subm
it=Log+OnclientId=09813emClientId=create=1095797686983remoteServer=false
Hey, guys,
I have updated the problem description on my website [
http://www.cs.ucf.edu/~cyin/httpClient/letter.html ], and now you can access the
debugging info [case II-- 2) --debugging info], testing results from proxomitron on
both IE and HttpClient [case II -- 3)].
If you check the
Tom,
Having the IE wire dump it should not be that difficult. Just carefully
analyze the wire dump and try to emulate the request structure (protocol
version, request headers) as close as possible.
For instance, the referer header in the second POST may well be the
missing bit:
Referer:
to your favorites. If so, please delete
that bookmark. You can bookmark the Welcome page instead.
Your browser doesn't support cookies, or you've set your browser to not accept
cookies. Please use one of the recommended browsers or set your browser preferences to
accept cookies. Contact your browser
to your favorites. If so, please delete
that bookmark. You can bookmark the Welcome page instead.
Your browser doesn't support cookies, or you've set your browser to not accept
cookies. Please use one of the recommended browsers or set your browser preferences to
accept cookies. Contact your browser
as it should), then follow the same path in HttpClient.
--Michael
-Original Message-
From: tom yin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 21, 2004 2:37 PM
To: [EMAIL PROTECTED]
Subject: url is Re: How to accept cookies in HttpClient.
Hello,
I've forgotten to tell you guys the url
Hi, Michael,
Thanks a lot for your info. It's weired...In my computer, after I clean cookies, I
will go to the error page if I click the link in this mail directly, but go to the
right login page if I copy the link to the address bar and press enter key.
The initial link is link1, http
. If not, download a tool like Ethereal to
help you do the monitoring and capturing.
--Michael
-Original Message-
From: tom yin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 21, 2004 3:44 PM
To: Commons HttpClient Project
Subject: RE: url is Re: How to accept cookies in HttpClient
Hi Tom,
This is a little verbose, but our product that uses httpclient reaches the logon page
with the cookes from the
second(logon frame) link.
We manage cookies externally to httpclient and sort-of emulate stepping
through the browser.
Here is the final link, request, 302 response, request
Hello, Steve,
Thanks a lot. I think you have almost found the real problem here. You are right,
cookies have been set and link has been redirected to a new link,
/sg1dgp9/tbiappt300/TbiaStatelessErrorPage, but this link, showing the error page, is
not the expected url. The error page has
Hi, guys,
I am doing a intelligent spider projects, and trying to grab data from sites
automatically. I don't know HttpClient a lot, but now I have collected data
successfully from various websites with the help of you guys. (Oleg has helped me to
solved a difficult problem yesterday. Thank
Hi Tom,
I get the same error page from Netscape, are you going through a proxy in IE?
Thanks,
Steve
-Original Message-
From: tom yin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 21, 2004 3:37 PM
To: [EMAIL PROTECTED]
Subject: url is Re: How to accept cookies in HttpClient.
Hello
Hello everybody,
When I'm sending requests to Yahoo search engine, I get this type of
warning message :
21 juil. 2004 09:56:32 org.apache.commons.httpclient.HttpMethodBase
processResponseHeaders
ATTENTION: Cookie rejected: $Version=0; B=deli0110fs8drb=2;
$Domain=.yahoo.com; $Path=/. Domain
refer to the
HttpClient cookie guide:
http://jakarta.apache.org/commons/httpclient/cookies.html
Oleg
-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 9:58
To: [EMAIL PROTECTED]
Subject: how to accept all cookies ?
Hello everybody,
When I'm
PROTECTED]
Sent: Wednesday, July 21, 2004 10:19
To: Commons HttpClient Project
Subject: Re: how to accept all cookies ?
Thank you for this answer, but I've already seen that :-(
Here's a part of my source code :
System.getProperties().setProperty(httpclient.useragent,
Mozilla/4.0 (compatible
-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 10:19
To: Commons HttpClient Project
Subject: Re: how to accept all cookies ?
Thank you for this answer, but I've already seen that :-(
Here's a part of my source code :
System.getProperties
source code and tweak it to your liking
Oleg
-Original Message-
From: Mathias Cianci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 10:38
To: Commons HttpClient Project
Subject: Re: how to accept all cookies ?
Thank you Oleg, now it works !
But I still have another cookie
());
for (int i = 0; i headers.length; i++)
{
final Header header=headers[i];
/* NOTE !!! remove the header from the group since we
* handle it here, and then we call the base class
*/
hg.removeHeader(header);
Cookie[] cookies=null;
try
{
cookies = parser.parse(
conn.getHost(),
conn.getPort
!!! remove the header from the group since we
* handle it here, and then we call the base class
*/
hg.removeHeader(header);
Cookie[] cookies=null;
try
{
cookies = parser.parse(
conn.getHost(),
conn.getPort(),
getPath(),
conn.isSecure(),
header);
}
catch (MalformedCookieException e)
{
// ignore
Hello, I am running into the same issue found by Eric
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=708
when running against tomcat 4.1.30.
My tomcat env is on windows XP, httpclient 2.0, jdk 1.4.2
The archive does not seem to have any conclusion yet.
Any suggestion?
-Dan
Dan
It was later discovered that different Tomcat connectors appear to have
different cookie parsing/formating logic. The problem shows up only when
the newer Coyote connector is being used.
!-- works fine --
Connector
className=org.apache.catalina.connector.http.HttpConnector
/show_bug.cgi?id=29377
Cookies with names containing blanks or starting with $ should be rejected by RFC2109
spec only
[EMAIL PROTECTED] changed:
What|Removed |Added
Status
/show_bug.cgi?id=29377
Cookies with names containing blanks or starting with $ should be rejected by RFC2109
spec only
Summary: Cookies with names containing blanks or starting with $
should be rejected by RFC2109 spec only
Product: Commons
Version: 2.0
/show_bug.cgi?id=29377
Cookies with names containing blanks or starting with $ should be rejected by RFC2109
spec only
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW
/show_bug.cgi?id=29377
Cookies with names containing blanks or starting with $ should be rejected by RFC2109
spec only
--- Additional Comments From [EMAIL PROTECTED] 2004-06-03 20:11 ---
Created an attachment (id=11756)
Patch against 2.0 (take 1
/show_bug.cgi?id=29377
Cookies with names containing blanks or starting with $ should be rejected by RFC2109
spec only
--- Additional Comments From [EMAIL PROTECTED] 2004-06-04 02:58 ---
Hi Oleg,
This looks good to me. My only suggestion would be to add a test case for the cookie
parsers
I'm using HttpClient 2.0-final to do a form-based login to a
Netscape-Enterprise 6.0 server (according to the HTTP headers). It uses
cookies to maintain the session.
When I run HttpClient in RFC2109 cookie mode, it works fine. However, when
I switch it to either compatibility or NETSCAPE_DRAFT
Chris,
In the 'strict' mode HttpClient 2.0 will send all cookies as one request header. I
believe that should take care of the problem. Some older HTTP servers appear to have
issues with multiple Netscape-style (version 0) 'cookie' request headers.
HttpClient 3.0 provides a granular option
/show_bug.cgi?id=28566
Handling sub-domain cookies.
--- Additional Comments From [EMAIL PROTECTED] 2004-04-27 09:16 ---
Abhishek,
This problem has already been addressed. I suppose you are using the latest CVS
snapshot, as the patch is against CVS HEAD. To make HttpClient send cookies as
one
/show_bug.cgi?id=28566
Handling sub-domain cookies.
--- Additional Comments From [EMAIL PROTECTED] 2004-04-27 20:50 ---
Hey Oleg,
Thanks for the quick response. You are FAST.
I am using the STABLE code since it will go into production pretty soon.
Probably before the next HttpClient
/show_bug.cgi?id=28566
Handling sub-domain cookies.
--- Additional Comments From [EMAIL PROTECTED] 2004-04-27 21:44 ---
Abhishek,
We are nearing the 3.0 alpha1 release with the development branch. Even though I
am convinced that in many areas the code quality in our development branch is
much
/show_bug.cgi?id=28566
Handling sub-domain cookies.
--- Additional Comments From [EMAIL PROTECTED] 2004-04-27 21:51 ---
If you do not mind, I'll apply the patch to the CVS HEAD and close the bug
Please do. The fix works
/show_bug.cgi?id=28566
Handling sub-domain cookies.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
/show_bug.cgi?id=28566
Handling sub-domain cookies.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone
/show_bug.cgi?id=28566
Handling sub-domain cookies.
--- Additional Comments From [EMAIL PROTECTED] 2004-04-25 22:02 ---
Works for me.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
/show_bug.cgi?id=28566
Handling sub-domain cookies.
--- Additional Comments From [EMAIL PROTECTED] 2004-04-24 12:05 ---
I cannot help mentioning that what those so called common browsers do is simply
silly, as the cookie spec requires the HTTP agents to differentiate between the
domain scope
/show_bug.cgi?id=28566
Handling sub-domain cookies.
--- Additional Comments From [EMAIL PROTECTED] 2004-04-24 12:09 ---
My apologies. The bug #25264 made it into 2.0 final. I'll look into the problem
anyhow.
Oleg
/show_bug.cgi?id=28566
Handling sub-domain cookies.
Summary: Handling sub-domain cookies.
Product: Commons
Version: 2.0 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
:39
To: Commons HttpClient Project
Subject: RE: question re: cookies
Ah yes, cookie headers that were manually set used
to get overridden. As far as I remember, that changed
a while back. Though I cannot tell whether the change
went into 2.0 or only into the development branch.
cheers,
Roland
cookies.
Optionally, you can also override method
processResponseHeaders() to do nothing,
so the incoming set-cookie headers will not
be parsed either.
cheers,
Roland
Kalnichevski, Oleg [EMAIL PROTECTED]
25.03.2004 09:29
Please respond to Commons HttpClient Project
To: Commons
reason
why the cookie is set with that path.
cheers,
Roland
Alvarez, Gil [EMAIL PROTECTED]
25.03.2004 07:37
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:question re: cookies
Hi, we're porting some old code to use
: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 10:51 PM
To: Commons HttpClient Project
Subject: Re: question re: cookies
Hello Gil,
two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state
to Commons HttpClient Project
To: Commons HttpClient Project
[EMAIL PROTECTED]
cc:
Subject:RE: question re: cookies
Thanks, yes, the old code pulled it out of the header directly, but the
rest of the story is that I save that cookie for later submittal
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2004-01-21 17:36 ---
I see this change didn't make it into rc3. It's going to be in 2.0 full, right
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2004-01-21 17:37 ---
Nevermind - I just saw the target of 2.1. Oh well.
-
To unsubscribe, e-mail: [EMAIL
Hi
I have the following problem.
I have a jsp servlet which is both server and client (using httpclient)
The client code performs a POST to another servlet on the same server.
I am trying to keep that POST part of the same session that the servlet
is working in, so that the second servlet has
Hello Sven,
browsers make requests in parallel for *one* user!
Meaning that all the cookies returned end up in the
same cookie store, as they do here.
A proxy servlet will make requests for different users
(browsers) and therefore has to maintain a different
state for each user. That state
browsers make requests in parallel for *one* user!
Meaning that all the cookies returned end up in the
same cookie store, as they do here.
A proxy servlet will make requests for different users
(browsers) and therefore has to maintain a different
state for each user. That state is typically
Hello Sven,
1. Cookie Container:
Let every session use it's own HttpState object. That's where
HTTP Client stores it's cookies. The only problem is that it's
not serializable, so it won't work with persistent sessions.
2. Thread Safety:
HTTP Client is thread safe as long as you use a thread safe
HttpClient.executeMethod
(HostConfiguration, HttpMethod, HttpState)
If you have used the same client from different
threads without specifying different states, that
might be a problem.
Well, i use this method now from different thread with different
HttpStates. I'd like to use even one
Hello Sven,
unless you have taken special precautions, the state object
is used to store cookies. Using the same state from different
threads can mix up the cookies from different clients pretty
badly.
Once you have the cookie problem solved, there is no issue
with using the same state object. I
unless you have taken special precautions, the state object
is used to store cookies. Using the same state from different
threads can mix up the cookies from different clients pretty
badly.
Once you have the cookie problem solved, there is no issue
with using the same state object. I dimly
Hi,
i'm working on a so called ProxyServlet which uses the Information
provided by the ServletContainer to deliver the Requests to another
Web-Server.
At present, i'm using the HttpMethod-Objects (GetMethod, PutMethod, ...)
and HttpClient.execute() to deliver the Requests to the other
Hi Sven,
Regarding the thread safeness, I suggest try using
MultiThreadedHttpConnectionManager. Instance it and put into
HttpClient's constructor.
Regards.
Andreas
On 12 Nov 2003 at 1:55, Sven Köhler wrote:
Hi,
i'm working on a so called ProxyServlet which uses the Information
provided by
/show_bug.cgi?id=24514
HEAD Method, IIS and Cookies
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
Hello,
I was wondering how to use HttpClient classes
and methods to get the value of a cookie. I want
to fetch the cookie named SessionID. How would
I do that? This is the code I have so far ...
PostMethod method = new PostMethod(url);
method.setFollowRedirects(true);
Dave,
Have a look at the the following example:
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/httpclient/src/examples/FormLoginDemo.java?rev=1.1only_with_tag=HTTPCLIENT_2_0_BRANCH
For more detailed information refer to the Javadoc of the HttpState
class and the CookieSpec
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-11-02 13:00 ---
Looks good to me.
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-11-02 03:10 ---
Created an attachment (id=8871)
Patch 3
-
To unsubscribe, e-mail: [EMAIL PROTECTED
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-11-02 03:11 ---
Oleg,
Agreed. Here's a new patch that completely ignores cookies.
Mike
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-29 20:02 ---
Mike,
I think CookieSpec#match methods should be overridden too. If cookies are not
parsed authomatically, they should not be sent automatically. One could
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 08:42 ---
Mike,
I think there's a little more elegant solution. All it takes is a cookie policy
that overrides CookieSpec#parse method and simply returns an empty
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 10:37 ---
Hello Oleg,
while there is no strict need to have a COOKIE_PARSING_ENABLED flag,
I still feel it is more elegant to have one. Not because it achieves
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 11:03 ---
Roland,
I respectfully disagree. What good does it make to have a cookie policy in
place and to not parse cookie headers? One would send a cookie
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 12:03 ---
Hello Oleg,
you're right that the cookie policy becomes pointless if cookie parsing
is disabled. Like the bass and treble knobs on my old amplifier become
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 12:25 ---
What about cases when you want to disable cookie parsing for some methods,
but have a cookie policy in place for those that do parse cookies?
Roland
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 13:28 ---
Oleg,
Unfortunately I think you are correct:) A new cookie policy is more appropriate.
Expect a new
patch later today.
Mike
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-29 03:56 ---
I've just started to write a new RejectAllCookiesSpec(or something like that) and I
have a question.
What do we want to do about cookie formatting
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-29 05:03 ---
Created an attachment (id=8797)
Patch 2
-
To unsubscribe, e-mail: [EMAIL PROTECTED
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-29 05:06 ---
Here's another patch. This one disables cookie parsing using a new cookie policy.
Mike
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-29 06:31 ---
Or else we could have two cookie spec params, one for parsing and one for
formatting. Then you define a new policy which neither parses nor formats
cookies
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 02:50 ---
Created an attachment (id=8760)
patch 1
-
To unsubscribe, e-mail: [EMAIL PROTECTED
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-28 02:52 ---
Roland,
I agree. I think disabling cookie parsing altogether makes more sense. Attached
above is a patch
that does exactly that. This change involves
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-23 06:22 ---
I wonder whether cookie policy is the right place to address this
particular issue. I'm using the HTTP Client as an implementation
of RFC 2616 (HTTP 1.1
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-23 07:36 ---
It's certainly a feature that should be provided by the stock implementation.
Every web browser has this feature, so I think we should provide it too
I'm trying to start using the HttpClient (I've always been instantiating
my own HttpConnections and Methods). I want to manually set a cookie to
be sent in the HttpRequest I am making, I can build the cookie myself,
setting the proper domain information. But its unclear to me what the
proper
Hi Mark,
You will want to add the cookies to the HttpClient's HttpState. Please
take a look at the following for an example:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/
examples/CookieDemoApp.java?rev=1.12content-type=text/vnd.viewcvs-
markup
Oleg has also recently
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
Summary: Ability to ignore (reject) cookies altogether
Product: Commons
Version: 2.0 Beta 2
Platform: All
OS/Version: Other
Status: NEW
Severity: Enhancement
/show_bug.cgi?id=24012
Ability to ignore (reject) cookies altogether
--- Additional Comments From [EMAIL PROTECTED] 2003-10-22 17:23 ---
I don't have a strong opinion on the matter, but it sounds like a good candidate
for contrib.
Mike
/show_bug.cgi?id=23839
cookies aren't working?
--- Additional Comments From [EMAIL PROTECTED] 2003-10-17 06:41 ---
RFC 2965 which specifies cookies defines a special handling for
local domains, which are extended by a dummy .local to generate
a domain name. However, I don't know whether
/show_bug.cgi?id=23839
cookies aren't working?
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution
/show_bug.cgi?id=23839
cookies aren't working?
--- Additional Comments From [EMAIL PROTECTED] 2003-10-17 08:59 ---
Oh my, shame on me. RTFM... read that fine message. I'm gonna try. Thanks.
-
To unsubscribe, e-mail: [EMAIL
/show_bug.cgi?id=23839
cookies aren't working?
--- Additional Comments From [EMAIL PROTECTED] 2003-10-16 09:31 ---
Created an attachment (id=8593)
cleanup logging showing the cookie getting lost
-
To unsubscribe, e-mail
/show_bug.cgi?id=23839
cookies aren't working?
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
/show_bug.cgi?id=23839
cookies aren't working?
--- Additional Comments From [EMAIL PROTECTED] 2003-10-16 10:01 ---
Oh, man. Of course, the last sentence was meant to be:
If it does NOT, simply set the domain attribute manually
/show_bug.cgi?id=23839
cookies aren't working?
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
/show_bug.cgi?id=23839
cookies aren't working?
Summary: cookies aren't working?
Product: Commons
Version: 2.0 Beta 2
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: Other
Component
/show_bug.cgi?id=23839
cookies aren't working?
--- Additional Comments From [EMAIL PROTECTED] 2003-10-15 14:42 ---
Tom,
Could you please follow the instructions of the HttpClient logging guide below
and produce the wire/debug log of the HTTP session?
http://jakarta.apache.org/commons
Yue,
That can be done, of course. Feel free to file a feature request in the
bugzilla.
Oleg
On Mon, 2003-10-06 at 19:43, Yue Luo wrote:
Hi,
I wonder if in the next release a method like deleteAllCookies()
could be added to HttpState. I am developing a driver for a web
benchmark and
Ernst,
Cookies are not deleted by HttpClient unless they are expired. I am pretty sure about
it
In your particular case there's a bug in the following piece of code
public AddReleaseTask() {
HttpState httpState = new HttpState();
httpState.setCookiePolicy
But that is the constructor which is called only once. So my code is
correct, right? If not, please elaborate on what I should do differently.
Ernst
On maandag 6 oktober 2003 11:59, Kalnichevski, Oleg wrote:
Ernst,
Cookies are not deleted by HttpClient unless they are expired. I am
pretty
are cookies deleted?
Ernst,
Cookies are not deleted by HttpClient unless they are expired. I am pretty
sure about it
In your particular case there's a bug in the following piece of code
public AddReleaseTask() {
HttpState httpState = new HttpState();
httpState.setCookiePolicy
[EMAIL PROTECTED]
To: Commons HttpClient Project
[EMAIL PROTECTED] Sent: Monday, October 06,
2003 11:59 AM
Subject: RE: Why are cookies deleted?
Ernst,
Cookies are not deleted by HttpClient unless they are expired. I am
pretty sure about it
In your particular case there's a bug
Ernst,
You might check out the troubleshooting guide. See about turning on
wire logging, for example. Then let us know what you find in the log.
The server can, of course, decide that it wants to expire your
cookies. The server doesn't need to return them with each response.
Cookies can
Hi,
I wonder if in the next release a method like deleteAllCookies()
could be added to HttpState. I am developing a driver for a web
benchmark and want to recycle HttpState instead of creating a new one.
Thanks.
Yue
-
To
/show_bug.cgi?id=11240
Cookies with ',' in the value string is not parsed correctly in some cases
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW
1 - 100 of 122 matches
Mail list logo
