On Fri, 2004-09-17 at 10:02, Ortwin Glck wrote:
Oleg Kalnichevski wrote:
Odi,
Which branch: HEAD or 2.0?
Oleg
2.0 as subject suggests.
All right, do not be hard on the old man.
Odi, I assume you recently upgraded the version of Tomcat that hosts the
test webapp? ;-)
We had
Folks,
Here's a small patch that tweaks the default method retry handler a
little. Currently HttpClient 3.0 stubbornly reties method that fail due
to a timeout or an SSL handshake exception, which is not the way it
probably should be.
Unless I hear loud complaints, I'll apply the patch tonight
Folks,
It looks like HttpClient 3.0 is not only ALPHA2 ready, it is almost code
and feature complete. There are only 5 open tickets targeted for 3.0
FINAL. It may take me just a couple of days to get all the remaining
issues dealt with, if needed.
been the Evil Comrade for some time now :)
Mike
On Sep 16, 2004, at 5:52 AM, Oleg Kalnichevski wrote:
Folks,
It looks like HttpClient 3.0 is not only ALPHA2 ready, it is almost
code
and feature complete. There are only 5 open tickets targeted for 3.0
FINAL. It may take me just
, Oleg Kalnichevski wrote:
Folks,
It looks like HttpClient 3.0 is not only ALPHA2 ready, it is almost
code and feature complete. There are only 5 open tickets targeted for
3.0 FINAL. It may take me just a couple of days to get all the
remaining issues dealt with, if needed
, Oliver
Oleg Kalnichevski wrote:
I only have a minor feature request for the preferences architecture: it
would be nice to be able to define default HttpMethodParams per
HttpClient instance. (i'm not sure, but you may already have taken care
of that).
I believe that can be fairly easy
Bülent,
This is a well known issue. The problem is that the use of non-ASCII
characters in the content disposition header (the one that includes the
file name attribute) violates the MIME spec.
See the following bug reports for details
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=30420
This will do the trick
===
HttpClient agent = new HttpClient();
PostMethod httppost = new PostMethod(
http://www.amfiindia.com/navreport.asp;);
httppost.setRequestBody(new NameValuePair[] {
new NameValuePair(cmbmf, 36),
new NameValuePair(btnview, View)});
Kiran
2004/09/13 17:11:23:081 IST [DEBUG] wire - -
WWW-Authenticate:NTLM[\r][\n]
2004/09/13 17:11:23:091 IST [DEBUG] wire - - WWW-Authenticate: Basic
realm=mailbox.iormyxintl.com[\r][\n]
The server actually prefers stronger NTLM authentication scheme over
insecure Basic one. HttpClient 2.0
David,
Just a few comments
(1) This is unrelated to your problem, but do make sure you release
connection when you are done with the method. In most cases HttpClient
will do its very best to automatically release the connection, but in
some cases (like the response content consumed partially)
site. Can I still install it on the client side ?
Thank you very much for your advices.
David
--- Oleg Kalnichevski [EMAIL PROTECTED] wrote:
David,
Just a few comments
(1) This is unrelated to your problem, but do make
sure you release
connection when you are done
Juan,
Most likely it is a server side issue. Take a look at this post. It
should explain the cause of the problem and can help find a fix for it
http://marc.theaimsgroup.com/?l=httpclient-commons-devm=109344163805313w=2
Oleg
On Thu, 2004-09-09 at 10:24, Juan Pedro Lpez Sez wrote:
Hello all.
Juan,
There's indeed no easy solution to this problem. There's a whole section
in our new exception handling guide on the issue of the transport safety
and HTTP methods' idempotency. The guide has not been published yet, as
it describes the new exception handling framework in the upcoming
Robert,
Status code 400 (Bad request) usually means that the server has rejected
the request as syntactically incorrect. This is very unlikely to be a
problem with HttpClient as such. The problem must be somewhere in the
layers that sit on top of it
Can it be that your application is targeting a
of the connection will be roughly the same,
presumably because the client of HttpClient buffers large reads.
On a 1Ghz machine, this patch means one million processor cycles that
can be put to a better use for *each* request. That's more than
benchmark optimization, I think.
-Eric.
Oleg
X-Smiles and TreeGrow have been added to the powered by HttpClient
application list
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/xdocs/applications.xml?r1=1.17r2=1.18diff_format=h
Oleg
On Mon, 2004-09-06 at 14:35, Mikko Honkala wrote:
Hi,
X-Smiles is an Open-Source XML
I personally feel extremely flattered by the fact that Spring framework
project chose to utilize HttpClient for their remoting solution.
However, like in case of Apache Axis, HttpClient is only one of many
transport options and thus completely orthogonal as far as the framework
itself is concerned
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oleg Kalnichevski
on currently uses the 2.0.1 implementation and we would rather avoid
having to change API to take advantageof this.
regards
Andre
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 2:11 PM
To: Commons HttpClient Project
Bjarne,
Could you define 'considerably' in some ANSI units? ;-)
I have just recently dealt with this problem. The empirical data that I
got appears to suggest that there's a (more or less) constant delta in
performance of ~2-3ms, which only makes a difference for relatively
small payloads. For
Makes sense. I'll start working on a patch.
Oleg
On Wed, 2004-09-01 at 19:43, Bjarne Rasmussen wrote:
Hi Oleg,
Forgot to mention:
It's not that BufferedInputStream#reset is better or faster than
PushbackInputStream#unread. The BufferedInputStream merely supports
mark/reset as a
No worries, Eric. It did come through.
http://marc.theaimsgroup.com/?l=httpclient-commons-devm=109385098103757w=2
Oleg
On Wed, 2004-09-01 at 20:17, Eric Bloch wrote:
Looks like my attachment didn't come through.
Did anyone see it? My sent box looks ok, but the message sent out via
the
uses the 2.0.1 implementation and we would rather avoid
having to change API to take advantageof this.
regards
Andre
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 2:11 PM
To: Commons HttpClient Project
Subject: Re
Is their something I am missing or is there a better way to
debug this?
Ken,
There is. Please refer to the HttpClient logging guide for details:
http://jakarta.apache.org/commons/httpclient/logging.html
If you need help interpreting the wire/debug log feel free to post the
relevant bits to
Hi Eric
Personally up to now I have not had too much of a hard time using
commons-logging with Websphere 5.0 and 5.1. Maybe I was just lucky
You may want to fork off the HttpClient 2.0 branch and host it on the
SourceForge, for instance. HttpClient 2.0 is stable and will not be
actively
Fabien,
If all you need is to maintain a distinct conversational state per
logical web application hosted on the same physical platform, you should
have just only one HttpClient instance and then keep different HttpState
instances per web application. It does take a bit of HttpState juggling,
-
De : Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Envoy : jeudi 26 aot 2004 10:50
: Commons HttpClient Project
Objet : Re: How to use two distinct HttpClients on the same web site
Fabien,
If all you need is to maintain a distinct conversational state per logical web
application hosted
Hi Dennis,
2004/08/19 11:56:07:490 CDT [WARN] MainMenu - -Web Service Exception:
he.commons.httpclient.HttpRecoverableException: Error in parsing the
status line from the response: unable to find line starting with HTTP
Usually this happens when the web servers being under heavy load is
Andre
I have been working with the NIO quite extensively for the last few
months. Here's my take on the problem. I believe as of HttpClient 4.0 we
should no longer maintain 1.2 (actually HttpClient is still fully jre
1.2 compatible) compatibility. That would enable us to leverage some of
NIO
Steve,
The cookie with the path attribute /insight may certainly not be sent
to a url starting with /insightreporting. So, HttpClient's behavior is
correct.
You can pursue one of three options to work the problem around.
(1) If you do not mind using ALPHA software you can consider using
I do not remember which earlier releases I used. I only remeber that it
did not have the rcX attached to it. I am not sure if it matters now. I
guess, the only thing we are concerned here is whether we can get
HttpClient performance better than JDK or not. If yes, then how do we
get it? I
On Fri, 2004-08-20 at 21:23, Zulfi Umrani wrote:
(3) HttpClient handsomely beats HttpURLConnection when streaming out
entity enclosing requests (POST, PUT)
Hi Oleg,
I am a bit skeptical about your test#3 for POST. I am doing POST myself
but the performance of HttpClient is not better than
+1
--
Vote: HttpClient 2.0.1 release
[x] +1 I am in favor of the release, and will help support it.
[ ] +0 I am in favor of the release, but am unable to help support it.
[ ] -0 I am not in favor of the
Andrea,
The code you contributed has been committed to the 2.0 branch. Many
thanks for this contribution.
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/pool/Attic/
I have applied some minor corrections to the source code to make
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
, Oleg Kalnichevski wrote:
On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote:
On Jul 13, 2004, at 8:03 PM, Michael Becke wrote:
Another way to handle this problem is to use the expect 100
continue
feature of HTTP. This feature is disabled in HttpClient by default,
as only a few servers
. A wirelog would be a good
start
Cheers,
Oleg
On Thu, 2004-07-15 at 20:54, Jennifer Ward wrote:
On Jul 15, 2004, at 11:02 AM, Oleg Kalnichevski wrote:
Jennifer,
What is the version of Tomcat you are using? Even though, as Eric
pointed out, Tomcat does not fully support the expect
Arturo,
When hit directly the site works just fine
[DEBUG] HttpConnection - -HttpConnection.setSoTimeout(0)
[DEBUG] HttpMethodBase - -Execute loop try 1
[DEBUG] header - - GET
/ClubPremier/Saldo/0,11100,11000.html?lang=0location=0ncuenta=0reqForm=1num_socio=767871601continuar.x=51continuar.y=12
:
!...
[content omitted]
By the way, I am running this on a Mac OS X system.
Thanks
Jen
On Jul 15, 2004, at 12:16 PM, Oleg Kalnichevski wrote:
Jennifer,
I ran a small
On Wed, 2004-07-14 at 18:10, Jennifer Ward wrote:
On Jul 13, 2004, at 8:03 PM, Michael Becke wrote:
Another way to handle this problem is to use the expect 100 continue
feature of HTTP. This feature is disabled in HttpClient by default,
as only a few servers support it correctly.
to be able to quote a
bug number to my project manager about why we can't use certificates
from a particular vendor.
Thanks
Tim
Oleg Kalnichevski wrote:
Tim,
This is believed to be a limitation of all Sun's JCE/JSSE
implementations up to Java version 1.5. You can try testing your
Jennifer,
I just recently had to respond to a very similar question.
http://marc.theaimsgroup.com/?l=httpclient-commons-devm=108940676906963w=2
To recap, whenever request body is streamed out (read directly from an
input stream) the request cannot be _automatically_ repeated.
There are three
Added to the 'HttpClient Powered' list of applications:
* Laszlo Presentation Server
* Celware WebRecorder
* Thin Client GUI Builder
On Mon, 2004-07-12 at 19:16, [EMAIL PROTECTED] wrote:
TCBuilder: Thin Client GUI Builder
TCBuilder is a GUI development framework based on Eclipse platform to
David,
What is the strongexact/strong version of JRE you are using? Early
releases of Sun's Java 1.4.0.x and 1.4.1.x were SO buggy that it is not
even worth the trouble looking onto the problem unless you can confirm
the problem is reproducible with Java 1.4.2.2 or above
Oleg
On Fri, 2004-07-09
:
Subject: Exception: org.apache.commons.httpclient.ProtocolException: Unbuffered
entity enclosing request can not be repeated
Dear Oleg Kalnichevski, Daer Jeff Dever,
i have since last 2 weeks a problem.
I' m using the apache/httpclient package (release currently used:
commons
Tim,
HttpClient 2.0 supports a reverse model compared to HttpURLConnection.
Instead of providing you with an output stream it can read the request
body directly from an input stream and write it to the socket output
stream for you
Folks,
The good thing about EasySSLProtocolSocketFactory is that its trust
manager does not require a custom truststore at all. It basically trusts
any certificate whose certificate chain contains only one entry, that is
the certificate itself, and delegates the verification of all other
-weight. For HttpClient's needs light-weight linked
hash-maps do just fine.
This said, an JMX layer sitting on top of HttpClient that provide MBeans
for HttpClient instances would be a great contribution
Oleg
Thanks,
Eric
Oleg Kalnichevski wrote:
Hi Eric
Thanks for bringing this up
Hi Eric
Thanks for bringing this up. HttpClient 3.0 allows for parameterization
of SO_SNDBUF and SO_RCVBUF settings. For HttpClient 2.0 (as well as for
3.0 when falling back onto the system defaults), however, it would make
sense to set a cap on the size of the send and receive buffers.
Feel
+1 (if my vote counts)
On Wed, 2004-06-30 at 01:21, Gary Gregory wrote:
This vote is to approve the public release of commons codec 1.3-RC1.
This will be a publicly announced RC to enable full feedback for a final
release in about two weeks if all is well.
Read the Release Notes:
Application page updated in CVS HEAD and 2.0 branch
Oleg
On Sun, 2004-06-27 at 23:29, Oleg Kalnichevski wrote:
Folks,
We have got two new submissions for the HttpClient powered page:
* Delosis Psytools
* actiWATE
If nobody objects I'll update the site within next two to four days
Eric,
Mark Diggory has started the refactoring of the multipart code but does
not seem to not have completed it. You should probably consult with him
regarding the direction of further efforts and API changes. Post a
message to the commons development list ([EMAIL PROTECTED])
stating
Hi Mohammad,
Once again, thanks a bunch for taking your time to review HttpClient
3.0a1. Until now you are pretty much the only one who gave us some
feedback on 3.0 API, which makes your contribution really appreciated
For specific points, see my comments in-line
2) The deprecated set
On Mon, 2004-06-14 at 22:42, Rezaei, Mohammad A. wrote:
I think if this code would use this.getParams() instead, it would work as
before. We've changed our code to use the httpMethod.setTimeout(), which
makes more sense; but I thought I'd bring it up as it is a non-trivial
change in the
Tim,
This is believed to be a limitation of all Sun's JCE/JSSE
implementations up to Java version 1.5. You can try testing your
application with Java 1.5-b2 to see if the problem has indeed been
fixed. Alternatively consider using IBM Java 1.4 or 3rd party JCE/JSSE
implementations which _may_ not
Lukas,
First of all, you need to know if your application actually hits the
server. It is pointless to troubleshoot the problem on the client side
if the request never reaches the server.
(1) What you tried trusting any certificate / disabling server
certificate validation?
(2) What is the
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 09, 2004 3:18 PM
To: Commons HttpClient Project; Lukas Bradley
Subject: Re: HttpClient Consultant Needed Immediately
Lukas,
First of all, you need to know if your application actually
On Wed, 2004-06-09 at 22:53, [EMAIL PROTECTED] wrote:
We're wanting to use HttpClient to do an HTTPS session that requires a user
certificate submission for authentication. Are there samples that anyone
can point me to on this topic?
Steve,
This may be what you want:
Odi,
I have no idea why the commit diff got trashed so badly. CVS content
appears correct.
Oleg
On Mon, 2004-06-07 at 09:42, Ortwin Glück wrote:
What's the problem with this diff? Why is it so bad?
[EMAIL PROTECTED] wrote:
olegk 2004/06/05 09:49:21
Modified:
On Mon, 2004-06-07 at 19:29, Dennis Cook wrote:
I was wondering when httpclient will be moved out of commons to the
sub-project level?
Dennis,
This issue has never been formally voted on, so take it as my personal
option only. I think it does not make sense to release HttpClient 3.0
out of
Christopher,
What makes you think that HttpClient dumps the stack? What I read from
the stacks tells me that is was not HttpClient#executeMethod
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at xxx..xx.xx.run(Unknown Source)
Then,
Dave,
You are not using HttpConnection class to establish connection with the
target server, are you?
Does you code look something like this?
HttpConnection conn = new HttpConnection(...);
conn.open();
HttpState httpstate = new HttpState();
GetMethod httpget = new
On Wed, 2004-06-02 at 17:58, Mark R. Diggory wrote:
So far I'm looking at something like:
HttpConnection connection =
client.getHttpConnectionManager().getConnection(client.getHostConfiguration());
connection.setConnectionTimeout(...)
But, my big concern is that this is again just bleed
Mike,
I think this clearly needs to be fixed. At the very least the logging
need to be more selective. I would also advocate changing the isStale()
behavior in the CVS HEAD. I see no benefit in calling close on a closed
connection. What do you think?
Oleg
On Thu, 2004-05-27 at 19:16, Michael
Satya,
We still need to document the new preference architecture and explain
its benefits.
Firstly and most importantly the new preference architecture is
hierarchical in structure which enables the users to apply a particular
option at any specific level:
Global -
HttpClient (agent) -
KMKU,
There's a bug that causes HttpClient 2.0 to produce erroneous wirelog
output. The bug has been fixed a while ago, but the code containing the
fix has not been released yet. You have to use nightly builds of
HttpClient 2.0 until 2.0.1 is released (can be obtained here
Steve,
The best thing to do is to consult the 'Default Initialization
Procedure' section of the Log4J manual
http://logging.apache.org/log4j/docs/manual.html
Usually all it takes to have Log4J properly configured is to make sure
that log4j.properties file is in the class path.
If still
Sam,
That would be a much appreciated contribution. We already have a bunch
of base TestCase classes that encapsulate shared commonalities for
different type of test cases. However, BaseBaseTestCase can still be a
great idea (apart from the name ;-)
Oleg
On Tue, 2004-05-18 at 18:45, Sam Berlin
+1
On Fri, 2004-05-14 at 01:32, Michael Becke wrote:
I propose that we mark the latest code in CVS HEAD as 3.0 alpha 1 and
proceed with a release. Please vote as follows:
--
Vote: HttpClient 3.0 alpha 1
Odi,
The sole purpose of 3.0 alpha1 release to get people look at the API and
give us some feedback on how it is shaping up. Alpha1 release is hardly
expected to be bug free
I really can't see why #28728 should be a release blocker
Oleg
On Fri, 2004-05-14 at 09:01, Ortwin Glück wrote:
-0
I
John
No reason other than HttpMethod HttpMethodBase being horrible
monstrosities badly in need of a compete redesign
Oleg
On Fri, 2004-05-14 at 09:02, Jesus M. Salvo Jr. wrote:
One small thing though. Why is setMethodRetryHandler() defined in
HttpMethodBase class instead of the HttpMethod
Sofya,
Connection: close in HTTP request is merely a hint which a
not-so-very-well-bred server may choose to ignore. Apparently this is
what WMS does. I am afraid your last option now is to implement a custom
HTTP connection manager that always closes connections upon release.
Oleg
On Fri,
Mike,
You rock! I think the 3.0 alpha1 release is ready
Oleg
On Thu, 2004-05-13 at 06:04, Michael Becke wrote:
Docs updated.
Mike
On May 12, 2004, at 5:53 PM, Oleg Kalnichevski wrote:
We are almost there. Before we can cut the release, though, there's one
tedious and laborious task
We are almost there. Before we can cut the release, though, there's one
tedious and laborious task to be taken care of. To help people identify
API changes, the new classes and methods must be properly marked with
the @since 3.0 tag. We (I in the first place) have been too
undisciplined to put
Anoop,
My guess is that some of the methods simply timeout while reading the
response from the server. Unfortunately, HttpClient does not handle this
situation well. Do not use HttpMethodBase#getResponseBody or
HttpMethodBase#getResponseBodyAsString methods. They are plain broken.
Both methods
Folks,
We are basically two bug reports away from the target for the 3.0a1
release. We are damn close. Before we cut the release, I feel there is a
few issues to be discussed first.
(1) Since this release is going to be incompatible with 2.0 API anyways,
I suggest HttpException be changed to
Otis,
Nowhere in your code do I see you set socket timeout. Connection timeout
determines the time HttpClient spends waiting a connection to be
established. The connection timeout does not affect socket I/O
operations.
Try this:
_client.getHttpConnectionManager().getParams().setSoTimeout(5000);
one left off.
Hope this clarifies things a bit
Oleg
Thanks,
Otis
--- Oleg Kalnichevski [EMAIL PROTECTED] wrote:
Otis,
Nowhere in your code do I see you set socket timeout. Connection
timeout
determines the time HttpClient spends waiting a connection to be
established
Hi Lili,
Do not give up too soon. I did test BASIC proxy (using Squid stable) +
NTLM host authentication and did work. Of course, I cannot rule out that
the problem is caused by some 'peculiarities' of Microsoft Proxy
implementation.
Please try disabling anonymous access to the host server and
it a shot. I tested HttpClient against IIS
4.x only
Oleg
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 05, 2004 11:36 AM
To: Commons HttpClient Project
Subject: RE: IIS (NTLM) + proxy server (NTLM or basic) problem
Hi Lili,
Do
Frank,
I thought the problem had been resolved. What's wrong with taking
MrPostman's code as a starting point and implementing the same thing
using HttpClient?
Oleg
On Tue, 2004-05-04 at 23:41, Min (Frank) Ni wrote:
Any luck in trying to get a page after logging into Yahoo with HttpClient ?
will take a look at it.
Thanks,
Mike
On May 2, 2004, at 6:08 PM, Oleg Kalnichevski wrote:
Folks,
I just updated the release notes doc to include personal contributions
made to HttpClient CVS HEAD since 2.0 was branched out (approx a year
from now)
http://cvs.apache.org
2, 2004, at 6:08 PM, Oleg Kalnichevski wrote:
Folks, I just updated the release notes doc to include personal
contributions made to HttpClient CVS HEAD since 2.0 was branched
out (approx a year from now)
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient
Folks,
I just filed a request for Bugzilla upgrade.
http://nagoya.apache.org/jira/browse/INFRA-73
Let's see if we have more luck taking that route.
I have an impression that Jira is to eventually supersede Bugzilla. All
the new project who have no or little Bugzilla legacy tend to opt for
the session cookie to be able to access
all of them without having to reauthenticate
Oleg
Frank
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 4:34 PM
To: Commons HttpClient Project
Subject: RE: Yahoo login with Httpclient
Frank
forwarding this mail to [EMAIL PROTECTED] Shall we
consider the move to Jira? How does everyone feel about it?
Oleg
On Wed, 2004-04-21 at 09:23, Oleg Kalnichevski wrote:
Good ${time of the day},
HttpClient has recently been promoted to the Jakarta subproject level.
As a first step
Roland,
As long as NDC is not supported by commons-logging HttpClient will not
be able to take full advantage of it. We can still think about some sort
of workaround as long as it does not make stock version of HttpClient
dependent on any particular logging toolkit. One idea that springs to
mind
Folks,
Any idea what to do with one? First of all, user name and password in
HTTP url is something completely new to me. Any idea what Sung-Gu had in
mind?
Oleg
On Fri, 2004-04-02 at 16:08, Gustav Munkby wrote:
hi,
If I do:
HTTPUrl url = new HTTPUrl(kurt, nicepass#, hostname, 80, path);
Frank,
You need to use so called form-based login. Have a look at this sample
application:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/examples/FormLoginDemo.java?rev=1.1.2.1only_with_tag=HTTPCLIENT_2_0_BRANCHview=markup
If it does not cut it for you, let me know. I may try
Cookie classes have got virtually 100% test coverage. Clover is horrible
way to spend a weekend [sigh]
Oleg
On Sat, 2004-04-24 at 18:51, Oleg Kalnichevski wrote:
Folks,
I think it is time we started using Clover reports for the CVS HEAD
development. Currently our test coverage is appalling
Folks,
I think it is time we started using Clover reports for the CVS HEAD
development. Currently our test coverage is appalling (meager 50%).
Since we have got a very flexible testing framework based on
SimpleHttpServer, we no longer have an excuse that certain complex
things cannot be adequately
during our nightly test suite and the coverage
reports are very great tools. You might want to consider waiting a week or more, as
Clover is right now in the process of finishing up their 1.3 release (they're on
1.3rc3 right now).
Thanks,
Sam
-Original Message-
From: Oleg
Good ${time of the day},
HttpClient has recently been promoted to the Jakarta subproject level.
As a first step in the transition process we would like to have a new
project created in the Bugzilla database and have Commons HttpClient
related entries migrated from Commons project to the new one
Folks,
I just spent over two weeks working extensively with SSL including
mutual client/server authentication. As soon as I get a breathing moment
I'll try to throw together a sample ClientAuthenticatingSocketFactory
and have it added to the contrib package. However, as far as JSSE is
concerned,
Patch committed.
Oleg
On Sun, 2004-04-18 at 19:09, Oleg Kalnichevski wrote:
Folks,
I have updated the applications and news pages in the wake of
HttpClient's promotion to the Jakarta sub-project level.
Please have a closer look at the applications page. I have taken liberty
Gary
Has the problem reported by Tom van den Berge been looked into?
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=108201900324974w=2
If not, I believe it should be
Oleg
On Sun, 2004-04-18 at 19:33, Gary Gregory wrote:
Hello all,
It seems to me that we should start the release
Folks,
I have updated the applications and news pages in the wake of
HttpClient's promotion to the Jakarta sub-project level.
Please have a closer look at the applications page. I have taken liberty
of reorganizing it somewhat, giving the open-source projects listed a
slightly better placement.
(patch against 2.0 branch)
Oleg,
A few suggested edits I'm not a great editor myself (I frequently
miss bevies of typos when my spouse asks me to review her writing), but
since nobody else responded, I figured I would.
Hopefully, my edits make sense.
Oleg Kalnichevski wrote
I would like to hope that our user base has expanded somewhat since the
2.0 final release. If anyone wants to be listed on our Applications
page http://jakarta.apache.org/commons/httpclient/applications.html,
please come forth.
Oleg
Lili,
Unauthorized access _should_ not be causing Maximum redirects (100)
exceeded, unless there's a bug either on the server or client side.
Could you please post the complete wirelog (with sensitive data
obfuscated), so we could try to determine what may be causing the
problem?
Cheers,
Oleg
101 - 200 of 474 matches
Mail list logo
