sense to reuse components from
outside, if possible. Unfortunately HttpComponents (in the person of
Oleg Kalnichevski) has repeatedly declared that he has no interest in
adding a multipart parser to httpcomponents, which would be (IMO) the
most important part. Instead he suggested to add
On Sun, 2007-04-15 at 09:48 -0400, Tom Muldoon wrote:
It appears that the HttpOnly cookie attribute is not recognized by the
CookieSpec class (in both HttpClient 3.0 and 3.1rc). i.e. the following
message is logged ...
CookieSpec - Unrecognized cookie attribute: name=HttpOnly,
On Tue, 2007-04-03 at 22:51 +1200, Simon Kitching wrote:
On Mon, 2007-03-26 at 15:51 +0200, Oleg Kalnichevski wrote:
On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote:
Hello,
I have seen the recent discussions on JCL 2.0.0 and a version without
autodiscovery.
Someone stated
[
https://issues.apache.org/jira/browse/FILEUPLOAD-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485970
]
Oleg Kalnichevski commented on FILEUPLOAD-131:
--
Folks,
I doubt HttpCore would be of any use here
On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote:
Hello,
I have seen the recent discussions on JCL 2.0.0 and a version without
autodiscovery.
Someone stated to stop any further development (with good reasons
behind) but I am
thinking different.
Please have a look at the (working)
Folks,
Please correct me if I am wrong, but the auto-discovery mechanism in
Commons Logging is believed to be the only major gripe about JCL.
What happened to the idea of releasing a version of JCL that retains the
full API compatibility with JCL 1.0.x and 1.1.x but with the
auto-discovery
On Thu, 2007-03-15 at 20:37 -0400, Gary Gregory wrote:
Hi All:
Any guesses on the release schedule?
Thank you.
I'll tag the release in SVN tonight and tomorrow is going to be the
official release date.
Oleg
Gary Gregory
Senior Software Engineer
Seagull Software
[EMAIL
On Sat, 2007-03-10 at 16:05 +1300, Simon Kitching wrote:
On Sat, 2007-03-10 at 03:38 +0100, Torsten Curdt wrote:
Definitely happy to give M2 a try; but I'd rather not change the
groupId on a bugfix release. We already have an M2 release in
FileUpload that didn't change the groupid so
On Wed, 2007-02-14 at 16:47 +1300, [EMAIL PROTECTED] wrote:
Perhaps this should have an @since tag added, as it's a new method?
Hi Simon,
This change does not actually affect the public API.
AutoCloseInputStream is a package private class and is not meant to be
imported by the end users.
Can
+1 to both
Oleg
On Sat, 2007-01-13 at 02:16 +0100, Dennis Lundberg wrote:
I have laid the finishing touches to commons-skin and feel that it is
ready for prime time. Therefor I would like to propose two votes:
1. Promote commons-skin from commons sandbox to commons proper.
[x] +1 Do
On Mon, 2006-12-25 at 16:24 +, [EMAIL PROTECTED] wrote:
Hi,
My apologies in advance, but I've been trying to subscribe to the HttpClient
dev mailing list, and failing. When I try to send an email to [EMAIL
PROTECTED], I get an email saying that user is not found.
Can anyone tell me
On Wed, 2006-11-01 at 11:59 -0500, Rahul Akolkar wrote:
Speaking of cross-commons, the JCL deps are all over the place. Which
is probably OK for now, since most variants are point releases (1.0,
1.0.2, 1.0.3, 1.0.4 being popular ATM).
Since JCL is the bottom rung of the ladder, we should do
On Wed, 2006-11-01 at 15:26 -0500, Rahul Akolkar wrote:
On 11/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
...
I wasn't implying we require JCL 1.1 now, but that when we do, we
diligently upgrade with each new release (for those components that
release). Otherwise we have Foo that needs
On Fri, 2006-08-18 at 12:55 -0400, Gary Gregory wrote:
Hello All:
Unlike version 3.0.1, the 3.1-alpha1 version is not compiled with debug
information.
I think compile.debug = true is a better default.
Done
Oleg
Thanks,
Gary
On Tue, 2006-05-16 at 22:27 -0700, Henri Yandell wrote:
It was when I only saw them occasionally at work. Seeing a fair few
here, so going to ask Jeff about them.
Hen
Henri,
We have had a similar problem with a number of issues (around 30) in
HttpClient that had their status set as
+1
On Tue, 2006-05-02 at 10:51 -0700, Henri Yandell wrote:
I'd like to call a vote that we switch to Jira. Here's the loose migration
plan:
* Make Bugzilla read-only
* Import Commons project in Bugzilla into Commons project in JIRA
This will pull over users, components, versions etc.
On Fri, 2006-04-28 at 23:58 +0200, Dennis Lundberg wrote:
Henri Yandell wrote:
On 4/28/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
I think that having a naming scheme is a good idea. From a user
standpoint I see no reason for keeping the project ids short (3-4
characters). If Jakarta
Henri Yandell wrote:
On 4/27/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Given this positive feedback so far, I'm going to email the infra@
mailing list to see how they would go about doing it _if_ we decided
we wanted to move.
I think we should be moving from
Stephen (and all),
We have been having some problems with the HttpComponents site [1],
which is rendered incorrectly in IE (and apparently IE only) when the
jakarta-maven.css style-sheet is being used. The left-hand menu does
not display anything unless I run the mouse pointer over it. With
On Tue, 2006-04-11 at 11:41 -0400, Gary Gregory wrote:
Hello:
What are the plans for the breakout of HttpClient into HTTP components?
Every time I look for the code, I realize that there are no
nightly-builds. The wiki [1] does not point to any code but I recall
finding a site describing
robert burrell donkin wrote:
On Thu, 2006-03-23 at 14:12 -0800, Martin Cooper wrote:
On 3/23/06, robert burrell donkin [EMAIL PROTECTED]
wrote:
On Thu, 2006-03-23 at 15:45 -0500, Sandy McArthur wrote:
On 3/23/06, Oliver Heger [EMAIL PROTECTED] wrote:
snip
-
On Wed, 2006-03-15 at 00:12 +, Stephen Colebourne wrote:
Progress to remove commons-build seems to be moving along nicley. So far
at least [lang], [io], [primitives], [collections], [codec], [logging]
and [betwixt] are done, plus [pool] unpublished.
Commons [HttpClient] converted as
of the HTTP spec that common
browsers tend to forgive. After all, HttpClient is not a browser, nor a
vacuum cleaner, it is what it is, an HTTP library.
Hope this explains our position
Oleg
Thanks
Oleg Kalnichevski wrote:
On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote:
...
I am
://wiki.apache.org/jakarta-httpclient/HttpClientApiRedesign
http://wiki.apache.org/jakarta-httpclient/ProjectGoalsPage
Feel free to consider submitting your code to HttpComponents at some
point of time
Oleg
Oleg Kalnichevski wrote:
Ryan Smith wrote:
Oleg,
Thanks for the reply.
Ok, the behavior can
to the httpclient-dev@jakarta.apache.org list. Just post
your suggestions / ideas / patches to the list and participate in the
discussion that will follow.
Cheers,
Oleg
Oleg Kalnichevski wrote:
Ryan Smith wrote:
Oleg,
Understood, thanks.
Well, in the future, if you would ever decide to offer
On Thu, 2006-02-16 at 15:39 -0500, Ryan Smith wrote:
If i try a GET request on
http://domain.com/site.html?x=1
And the domain.com web server does a 302 redirect to : /site.html?y=2
HttpCleint thinks its a Circular redirect b/c its *JUST* looking at the
uri, not the uri + query string.
On Thu, 2006-02-16 at 17:24 -0500, Ryan Smith wrote:
...
I am using 3.0 RELEASE
But i checked out the latest snap shot code, and the logic in
HttpMethodDirector.java only checks for the URI, not URI + Query string.
Ryan,
I think this behavior is correct. It was implemented per this bug
On Mon, 2006-01-30 at 11:50 +0530, PARVEEN GARG (GR/EIL) wrote:
Hello Oleg,
This means Commons HTTPClient does not include any encryption
algo of its own.
Please confirm.
I can confirm that.
Oleg
Regards,
Parveen
On Wed, 2006-01-25 at 10:50 +0530, PARVEEN GARG (GR/EIL)
On Wed, 2006-01-25 at 10:50 +0530, PARVEEN GARG (GR/EIL) wrote:
Hello all,
I have a question regarding encryption and export control. Does Apache,
Commons HTTPclient include any SW encryption that restricts export (i.e.
special ECCN code)?
Best Regards,
Parveen Garg
Parveen,
Commons
On Tue, 2005-12-13 at 13:41 -0500, David Smiley wrote:
Last I recall, the HTTPClient team abandoned the idea of an NIO based
HTTPClient implementation since testing that Oleg did turned up poor
results.
David,
This is not exactly what the outcome was. So far I have seen no evidence
of
Torsten,
This is a conscious design decision. The reason for these wrappers'
existence is to ensure the reliability of persistent connections.
(1) AutoCloseInputStream ensures the entire content body is consumed
upon connection release thus making it reusable for other requests.
Consider the
On Tue, Apr 05, 2005 at 11:46:49AM -0400, James Mitchell wrote:
James, could you point me to any ASF document that regulates storage of
dependencies in the repository, please?
There may or may not be such a document. I'm not really interested in
trying to be the binary police. I just
, though
Oleg
On Tue, Apr 05, 2005 at 06:25:42PM +0200, Ortwin Gl?ck wrote:
Oleg Kalnichevski wrote:
If you would like me to setup the same download-dependencies for
httpclient, I'd be happy to help. The example above uses ibiblio, but
you can use any url.
We would very much
On Tue, 2005-04-05 at 18:57 +0200, Ortwin Glück wrote:
Oleg Kalnichevski wrote:
Odi,
I have not looked at the proposed solution, so I may be wrong here, but
I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an
external repository (such as ibiblio). If it is indeed
On Mon, 2005-03-07 at 19:07 -0400, Derek Lohnes wrote:
I was looking for a jar containing the contrib classes for SSL. Can some
tell me what the intention is for this stuff will it be packaged as part
of the distribution?
Hi Derek,
We may eventually consider moving the
On Sat, 2005-02-05 at 10:45 +, Stephen Colebourne wrote:
From: Kevin A. Burton [EMAIL PROTECTED]
snip
Is there a pattern of projects moving from the commons to a top level
jakarta project?
HttpClient is the only one that has tried to go to be a subproject within
Jakarta. However it
Brett,
Unfortunately this doesn't help. The trouble is that junit resource
files do not seem to be copied to HOME/target/test-classes/
If you declare the resources inside your unit test element they should be:
unitTest
includes
...
/includes
resources
resource
On Mon, 2005-01-31 at 06:44 +0800, Brett Porter wrote:
Yuck :) Can we help fix this?
IIRC, other people having problems have corrected them by using
/org/apache/commons/... (note leading /).
Brett,
Unfortunately this doesn't help. The trouble is that junit resource
files do not seem to be
+1
On Sat, 2005-01-22 at 13:31 -0500, Tim O'Brien wrote:
Alright a sufficient amount of time has passed for public comments and
testing.
This is a vote thread for migrating commons to SVN. If this vote
passes, I'll contact Justin and schedule the least disruptive migration
time possible.
Folks,
I took a quick look at the test SVN repository. All looks sane to me. I
checked out HttpClient 3.0 (trunk) and HttpClient 2.0.x
(HTTPCLIENT_2_0_BRANCH) snapshots. They seems identical to the CVS
content of two days ago. As far as I am concerned we should be good to
take the plunge
Cheers,
And what if we create an HttpClient instance with
HttpClient agent = new HttpClient();
in a request, do we need any shutdown() like method call?
Guillaume,
Ideally you do. Per default HttpClient uses SimpleHttpConnectionManager
as its connection manager. Even though
And how often does that happen in a course of one working day? I'd say
not that often. I do agree with Roland that a startup script written in
VBScript appears to be the best solution for the problem
Oleg
On Fri, 2004-10-22 at 10:54, Ortwin Glck wrote:
Roland Weber wrote:
Wait, here is
Massimo,
Calling HttpMethod#releaseConnection() does not guarantee that the
active connection will be closed. HttpClient _always_ tries its best to
reuse open connections. Whenever a connection can be kept alive,
HttpClient will keep it alive. That effectively means that when an
HttpClient
Sudhakar,
Here's a few sample apps that you may find useful:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/?only_with_tag=HTTPCLIENT_2_0_BRANCH
I do not know of a good comparison of HttpClient vs. competition
concentrating primarily on the file upload functionality.
On Wed, 2004-10-20 at 11:50, Michael McGrady wrote:
Not sure what you are saying here, Gluck. Can you explain? I
personally see these two implementations as competing applications.
Michael,
These are complementary technologies. FileUpload implements the
receiving/decoding logic, whereas
intention to proceed with the migration if no one speaks
out.
Oleg
On Mon, 2004-10-11 at 16:12, Oleg Kalnichevski wrote:
Folks
Due to the recent upgrade of HttpClient to a full project in Bugzilla
JIRA no longer has a definitive edge over Bugzilla. Nonetheless, JIRA
still a newer
and implement a content
retrieval/buffering logic that is best suited for your specific
application.
Hope this helps
Oleg
Regards
Vinay
On Thu, 14 Oct 2004 19:02:23 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
Please upgrade to HttpClient 2.0.2 and retest. In the future please do
is recommended.
Regards
Vinay
On Thu, 14 Oct 2004 19:02:23 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
Please upgrade to HttpClient 2.0.2 and retest. In the future please do
send your response to the list
Oleg
On Thu, 2004-10-14 at 18:58, Vinay Murthy
Vinay,
What HttpClient and JRE version are you using?
Oleg
On Thu, 2004-10-14 at 18:31, Vinay Murthy wrote:
Hi,
I am using httpClient as a part of htmlUnit. I tried logging into my
mail account (Yahoo!), but unfortunately ended with an exception
trace:
java.net.ConnectException:
Ramiel,
I think you came pretty close. Two things require minor corrections
(1) Content-Type
HTTP POST per default uses so called URL encoding when submitting HTML
forms. Setting the content type to 'text/plain' may cause some web
servers to misinterpret the request parameters
Try this instead
On Tue, 2004-10-12 at 03:42, Michael Becke wrote:
Hi Oleg,
How do we go about adding versions, target milestones, etc?
Mike
Mike,
We still will have to ask the Infrastructure. The good news is creating
new versions and milestones in Bugzilla takes no special trickery, so it
_should_ be
On Tue, 2004-10-12 at 04:04, Michael Becke wrote:
Hello All,
I've been starting to refactor some of the webapp test and have come
upon a bit of a problem. I'm not terribly familiar with the
SimpleHttpServer setup so perhaps there is simple solution that is
eluding me. The problem is
, Oleg Kalnichevski wrote:
On Tue, 2004-10-12 at 03:42, Michael Becke wrote:
Hi Oleg,
How do we go about adding versions, target milestones, etc?
Mike
Mike,
We still will have to ask the Infrastructure. The good news is creating
new versions and milestones in Bugzilla takes
Oh, man. No thunder, just emotional devastation. It has been quite an
ugly squabble and have made a few non-friends among the Infrastructure
folks.
Anyways, we need to make an announcement on the site in order to preempt
(some of) the confusion among the users.
Finally this issue is done with
Javen
HttpClient 2.0.x represents the stable branch whereas HttpClient 3.0 is
still in ALPHA development stage and may be subject to API change. We
are planning to freeze the 3.0 API quite soon and start working toward
the code freeze and a first stable release
For detailed information on new
Hi Sudhakar,
Why should a personal opinion of one guy hurt? We are all entitled to
have our own opinion. As imperfect as HttpClient may be, it is still
being used by numerous state of the art projects such as Spring
framework, and to me that counts more than an opinion of one guy.
1. API is
HttpClient project has taken a very important step toward becoming a
full-fledged Jakarta level project. From today, HttpClient is a separate
project in Apache Bugzilla issue tracking system. It is no longer a
component of the Commons project. Please use the following details when
filing bug
Folks
Due to the recent upgrade of HttpClient to a full project in Bugzilla
JIRA no longer has a definitive edge over Bugzilla. Nonetheless, JIRA
still a newer and more flexible system which can potentially make our
life and that of our users simpler.
Hi Roland
I agree this makes sense. I am not sure, though, whether we can
reasonably expect things to happen in one 'Big Bang': mailing lists, new
CVS repository, web site, JIRA migration and so on. Most likely not.
Besides, unless we start getting MASSIVELY more feedback on 3.0, I am
not sure
Zulfi,
According to the log the request body does get written to the socket
output stream:
[DEBUG] wire - - SOAP-ENV:Envelope
...
ello/SOAP-ENV:Body/SOAP-ENV:Envelope
So, really I do not think this has anything to do with HttpClient given
the data.
Do try out different settings:
Folks,
I would like to make ChunkedInputStream a little more reusable by making
HttpMethod parameter optional. Please let me know if you agree/disagree
Oleg
***
The information in this email is
Madeleine,
If you activate wire/context logging in your application you'll get more
details on what exactly goes wrong
http://jakarta.apache.org/commons/httpclient/logging.html
If you need help reading the log, feel free to post it to this list. Do
obfuscate security sensitive bits such as
Bob,
You are absolutely right about method.getHostConfiguration() taking
precedence over client.getHostConfiguration(). However, HttpClient does
copy the proxy information from the agent host config to the method host
config. So, that should not be the reason for proxy problems Madeleine
has been
Zulfi
HttpRecoverableException: Software caused connection abort: recv
failed usually means that the connection was closed on the server side
while HttpClient was still reading the response. The is more likely to
be the server side problem.
What exactly do you mean by occasionally HttpClient
Zulfi,
My only guess is that this is a thread synchronization related problem,
as the problem appears to be irregular.
How do you set the request body? As an InputStream? How do you set the
content length? Explicitly or as CONTENT_LENGTH_AUTO? Can it be that the
input stream is exhausted before
+1
On Wed, 2004-10-06 at 03:48, Michael Becke wrote:
After a little delay... I propose that we mark the latest code in CVS
HTTPCLIENT_2_0 as 2.0.2 and proceed with a release. Please vote as
follows:
--
Vote:
Actually the new Preferences Architecture is quite neat and great if it all
works. It is only the HostConfiguration that does not work and I would love
to figure out why.
Vikram,
I believe the problem with HostConfiguration has been fixed in CVS HEAD.
We'd love to hear from you if now you
Jeff,
Sometimes, usually when under heavy load, the web server may be able to
receive requests but unable to process them due to low resources (most
commonly worker threads). In such a case the web server may simply have
no other choice but to drop the connection without sending back any
status
Pavel,
It does seem a little unusual and does appear likely to be a problem on
the server side. 'Connection reset' error usually occurs in the
following two cases:
(1) the server drops the connection on the unsuspecting HttpClient while
it is still busy transmitting the request. The most common
Jason,
Take a look at the HttpClient tutorial and the authentication guide.
That should get you started:
http://jakarta.apache.org/commons/httpclient/tutorial.html
http://jakarta.apache.org/commons/httpclient/authentication.html
Same code can be found here:
, and if so is desired,
this can be disabled. The thread management is entirely responsibility
of your application. One does not have to use one thread per socket
model even without NIO
I have seen that Oleg Kalnichevski has already expressed his
views several times on the subject, and I have seen
Feasible approach is to have one monitor thread checking on the status
of active connections or/and processing incoming connections, and a
number of worker threads in a shared pool to do the actual work.
Actually since probably most people using httpclient with many
connections would
Is it considered safe to interrupt the execute task that way? Is
method.releaseConnection() the way to go for full cleanup of
underlying resources, or the interruption might leave things in a
bad state?
There's no definitive answer to this question. TimeoutController does
not actually
Hi St.Ack,
Your feedback is really appreciated. I am quite happy that we now have
one less development list to spam ;)
See my comments inline
The upgrade took way longer than I anticipated, a couple of days rather
than a couple of hours. While some of the time was spent on refactoring
any key to continue . . .
Please reply at your earliest convenience.
Chris
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 5:10 PM
To: Commons HttpClient Project
Subject: RE: HttpClient + HTTPS + NTLM Authentication = HTTP
That'd be grand if its possible (We like the IBM JVMs' speed and more
detailed thread dumps). We used to subclass httpclient so we could do
the below, moving the setting of the timeout till after the open.
HttpClient 3.0 now sets timeout, etc., after the open seemingly so our
subclass
Probably that's not the way it is supposed to be. I'll see what can be
done about it.
Oleg
On Wed, 2004-09-29 at 11:53, Ortwin Glck wrote:
Vikram Goyal wrote:
Hello,
I am not sure if this is a bug or I am not running this right.
I am trying to get the preferences architecture to
Vikram,
I hope what is to follow will clarify things a little
(1)
===
HostConfiguration host = new HostConfiguration();
host.setHost(www.google.com);
===
These are
I am testing the new Preferences Architecture before writing about it in a
Book that I am working on. I have spent the whole of today looking at the
source code but could not locate the problem, so it is bugging me now. It
makes sense, the architecture I mean, but it is just not working
+1
On Wed, 2004-09-29 at 14:19, Michael Becke wrote:
I propose that we mark the latest code in CVS HTTPCLIENT_2_0 as 2.0.2
and proceed with a release. Please vote as follows:
--
Vote: HttpClient 2.0.2 release
Actually the new Preferences Architecture is quite neat and great if it all
works. It is only the HostConfiguration that does not work and I would love
to figure out why.
Vikram,
Basically it appears that (1) we assume it should work one way, (2)
whereas you assume it should work quite the
Bob,
There's no special magic involved. Make sure you use
HttpMethod#getResponseBodyAsStream, which will return the raw input
stream, and not its buffering counterparts
HttpMethod#getResponseBodyAsString and HttpMethod#getResponseBody.
You should not worry about chunking. HttpClient will decode
by the HttpMethodBase during an execute) automatically buffers the response.
Is this true, or am I totally misreading the signs?
Thanks,
Bob
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 3:04 PM
To: Commons HttpClient Project
Subject: Re
buffers the
response. Is this true, or am I totally misreading the signs?
Thanks,
Bob
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 3:04 PM
To: Commons HttpClient Project
Subject: Re: streaming responses
the 3.0 HttpClient. Since getting it to compile was easy, I
suspect that the rest of it will be fairly straightforward too.
-Eric.
Oleg Kalnichevski wrote:
As far as I know the following projects rely on HttpClient 2.0 as a
required or optional dependency
* Apache Jakarta Slide (http
Please clarify the following.
1) Do I need to instantiate HttpClient only once? (using Singleton).
You should. There's nothing wrong with having multiple HttpClient
instances, but we generally recommend having only a single one
2) Can I use MultiThreadedHttpConnectionManager in this
Christopher,
What is exactly the problem?
The authentication succeeded:
HTTP/1.1 200 OK
Session cookie has been sent:
ASPSESSIONIDAQQBDABR=LMNNMHNALPPKIBENMNNANHGP
NTLM authentication scheme is a stateful one and requires multiple
challenges/responses. The first 401 Access Denied response is
A HREF=http://www.netscape.com;Netscape/A
or A HREF=http://www.microsoft.com;Microsoft/A browser.
/FORM/
Thanks again for your help, Oleg.
Christopher
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 4:29 PM
To: Commons
think.
-Eric.
Oleg Kalnichevski wrote:
Eric,
This patch makes a difference for only relatively small payloads when
the response content is about the size of the status line + headers. In
most (real life) cases the performance gain is virtually negligible.
This is more about
Thanks, Adam
Should we decide to go on a spamming spree, these may also become
potential victims ;-)
Oleg
On Tue, 2004-09-28 at 20:37, Adam R. B. Jack wrote:
On Mon, 2004-09-20 at 22:50, Oleg Kalnichevski wrote:
As far as I know the following projects rely on HttpClient 2.0
Mark,
We do not have a full-blown tutorial on this subject as SSL
authentication is basically is out of HttpClient scope.
This sample code does, however, have extensive javadocs on the matter.
My belief at this point is that Oracle is only sending the client
certificate to browser (IE) based clients. That would explain the problem. I
have created an Oracle TAR, to see if this is an Oracle problem.
Dale,
This assumption can be easily tested. The only way the target web server
can
Dale,
Do you know if the client authentication has been configured as required
or optional? Does the server reject the connection when attempt is made
to authenticate with an invalid certificate? The fact that IE pops up
the certificate dialog does not not actually mean that the server
validates
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:
Dmitriy,
'enKoo WebApps' has been added to the list of HttpClient powered apps.
Check it out at:
http://jakarta.apache.org/commons/httpclient/applications.html
,
Oleg
On Tue, 2004-09-21 at 20:42, Dmitriy wrote:
Hi
I'd like to announce that enKoo's application WebApps is HttpClient
Sep 2004 22:50:20 +0200, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
As far as I know the following projects rely on HttpClient 2.0 as a
required or optional dependency
* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
* Apache Jakarta Cactus (http://jakarta.apache.org/cactus
Robert,
It is a known problem with HttpClient 2.0.
There are three possibilities:
(1) Use HttpClient 3.0, which provides fine-grained control over
protocol compliance leniency.
(2) Disable auto redirect and handle redirects manually
As far as I know the following projects rely on HttpClient 2.0 as a
required or optional dependency
* Apache Jakarta Slide (http://jakarta.apache.org/slide/)
* Apache Jakarta Cactus (http://jakarta.apache.org/cactus/)
* Apache Axis (http://ws.apache.org/axis/)
* Apache XML-RPC
+1
On Fri, 2004-09-17 at 04:12, Michael Becke wrote:
It looks like we're ready for a 3.0 alpha 2 release. Please vote as
follows:
--
Vote: HttpClient 3.0 alpha 2 release
[x] +1 I am in favor of the release,
On Fri, 2004-09-17 at 09:49, Ortwin Glck wrote:
Some of the Cookie tests are currently failing. Can some Cookie expert
have a look into this?
Odi,
Which branch: HEAD or 2.0?
Oleg
-
To unsubscribe, e-mail: [EMAIL
1 - 100 of 474 matches
Mail list logo
