On Mon, 2011-10-03 at 10:03 +0100, sebb wrote:
On 29 September 2011 00:52, Milamber milam...@apache.org wrote:
Hello,
The third release candidate for JMeter 2.5.1 has been prepared, and your
votes are solicited.
This release fixes mainly some bugs appeared since JMeter 2.5, and
(woolfel AT a.o)
* Henri Yandell (bayard AT a.o)
* Rahul Akolkar (rahul AT a.o)
* Oleg Kalnichevski (olegk AT a.o)
* Rainer Jung (rjung AT a.o)
* Philippe Mouawad (pmouawad AT a.o)
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Sebastian Bazley
be appointed to the office of Vice President
/httpclient/3.0/cookies.html
* Cross-site redirect support
http://jakarta.apache.org/commons/httpclient/3.0/redirects.html
We are looking at the API freeze in four to six week time. Your feedback
would be greatly appreciated
On behalf of the Jakarta HttpClient committers
Oleg Kalnichevski
Is it just that JCE/JSSE weren't combined with 1.2? So to be only
dependent on a single JDK [and not additional Sun jars], you'd need 1.4?
Not really. One can still happily run HttpClient on Java 1.2 (without
JCE JSEE installed at all) as long as HTTPS and NTLM are not used. An
attempt to
The reason for JDK 1.4 is due to trying to get more in. I think a JDK1.2
version should exist too, but it would not contain HttpClient (?) which I
thought might be 1.4 dependant now for SSL and would not include BeanUtils
with the current api munging.
Httpclient is still run-time
Folks,
I got indeed swamped with e-mails after having subscribed to Geronimo's
mailing list. sorry about that.
I already responded to Tim that I had no objections. Feel free to rename
the methods as you see fit.
Oleg
On Thu, 2003-08-14 at 04:50, Henri Yandell wrote:
Unless Oleg is a member of
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
Mark,
Coincidentally, we just ended up deprecating HttpConstants class, having
migrated all the relevant functions to a new class named EncodingUtil. I
can't help thinking that Codec may also be a good place for what is now
EncodingUtil in HttpClient.
Cheers,
Oleg
On Tue, 2004-01-13 at 18:10,
Tim, Gary
Currently [Codec] is still Java 1.2 compatible. And yes, there are
[Codec] users who would like it to stay that way at least for some time.
Not that we enjoy working around Java 1.2 limitations that much, but we
simply have obligations to our users as well (there are several
projects,
Gary,
I have submitted quite a while a draft implementation of three new
codecs: quoted-printable codec (partial implementation), Q-codec and
B-codec. Nothing terribly exiting, but all there may come quite handy in
[HttpClient] and [FileUpload].
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 15:39
To: Jakarta Commons Developers List
Subject: RE: [codec] RFC1522 codecs partial implementationofquoted-
printable codec
Gary,
We do need Q-codec in [HttpClient] one way
Mladen, Alex, et al
Interesting enough just a few weeks ago I also encountered a similar
need of a lightweight server micro-kernel. After having looked around I
found nothing which I thought was close enough to what the requirements
were, so I ended up writing all that plumbing code myself from
Alex,
On Mon, 2004-04-12 at 17:34, Alex Karasulu wrote:
Yeah this is a very sad point indeed. Luckily I can focus on other things
until SSL arrives and 1.5 is the standard production JDK in prominence.
With so many REALLY controversial changes to Java language long may be
our wait for 1.5
AFAICT even 1.5 NIO doesn't support SSL directly.
The trick is to use the SSLEngine and drop the SSLServerSocket altogether.
Well, it does.
http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/jsse-tiger-beta1.html#SSLENG
The trouble is that it may takes years for 1.5 to become
On Mon, 2004-04-12 at 19:58, Mladen Turk wrote:
Well, it does.
http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/jsse-t
iger-beta1.html#SSLENG
Read carefully :)
It uses like I said SSLEngine not the SSLServerSocket for non-blocking io
that can be done with the 1.4 too.
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
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:
+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:
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,
+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.
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
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 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
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 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
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, 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
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 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 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
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 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
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 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
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
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
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
+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 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
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 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 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
+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 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
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 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
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 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)
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
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,
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
. I'm still
trying to figure out how to control the generation of the nav bar.
Check it out!
http://jakarta.apache.org/commons/httpclient/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Oleg Kalnichevski [EMAIL
with // (e.g.
//yadayada/blabla ). The BNF for this part is:
net_path = // authority [ abs_path ]
abs_path = / path_segments
rel_path = rel_segment [ abs_path ]
Mike
On Saturday, January 25, 2003, at 12:25 PM, Oleg Kalnichevski wrote:
Sung-Gu
, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oleg Kalnichevski [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
But such is with coding style, everyone has their own variation. There
are such things as Jalopy that will reformat code so you can format in
your own style and convert later. While this was helpful, I spend more
time looking at code than writing code, which made it harder to
]
--
Oleg Kalnichevski [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Patch applied.
Thomas, please let me know if that fixes the problem for you
Cheers
Oleg
PS: my apologies for mixing up your first and last name
On Mon, 2003-02-03 at 19:41, [EMAIL PROTECTED] wrote:
All right. We did talk about different things. Now I see the problem. Whoever
initially
Hi Sung-Gu
On Tue, 2003-02-04 at 11:37, Sung-Gu wrote:
Hi Oleg,
Again... well..
Ok... let me try to make you understand it again. HmmHmm...
Let's assume I am stupid
BTW, sorry to bother you that I haven't got you to get it right away
at that time even with a diagram and still... :(
Alan
I suppose you want to have a cookie that never expires. Currently
Cookie#Cookie(String, String, String, String, int, boolean) constructor
blindly assumes max age parameter to be a positive integer. To work the
problem around you can use Cookie#Cookie(String, String, String, String,
Date,
Laura
Finally, there's someone who can read Sung-Gu's mind!
All right. A simple phrase There are charsets that are not adequately
represented in Unicode by Sung-Gu would have put the discussion into a
completely different perspective. And of course, Sung-Gu's stoical
refusal to provide a test
Rob,
I am working on fixing the problem
Many thanks for tracking it down
Oleg
On Thu, 2003-02-06 at 00:21, Rob Owen wrote:
The new EntityEnclosingMethod is great and looks like it might be able to support
HTTP 1.0 servers with the 3 second wait for a 100-Continue response. There is a
problem
support the lowest reasonable version. This has always been
jre1.2.x
Which reminds me, next time I better actually compile the release build
with 1.2 ... I'll update the release process.
Jandalf.
Oleg Kalnichevski wrote:
I am also of opinion that for the time being Java 1.2.2 should
Odi, Jeff
I tend to interpret the word of RFC the same way. However, the RFC
appears a bit fuzzy on whether it is permissible to include
Transfer-Encoding: chunked response header without actually providing
any content in response. Anyways, to an extent this is irrelevant. We
have to coexist with
Mike,
Looks really good to me. It's a welcome improvement, which will finally
allow for cookies to be put on a separate header line each
Great work!!!
Oleg
On Sun, 2003-02-09 at 00:18, [EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE
;
+
+/**
+ * Logs data to the wire LOG.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED];Oleg Kalnichevski/a
+ *
+ * @since 2.0beta1
+ */
+
+class Wire {
+
+/** Log for any wire messages. */
+private static final Log WIRE_LOG = LogFactory.getLog(httpclient.wire);
+
+private static void wire
java.util.ArrayList;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
+/**
+ * A utility class for parsing http header values.
+ *
+ * @author Michael Becke
+ * @author a href=mailto:[EMAIL PROTECTED];Oleg Kalnichevski/a
+ *
+ * @since 2.0beta1
+ */
+public class
Hi James,
I am known as Cookie Taliban here for imposing strict, at times literal,
interpretation of cookie related RFCs ;-)
First off all, RFC 2965 has not been implemented yet, even though
HttpClient offers limited support for set-cookie2 headers.
Currently HttpClient per default uses RFC2109
On Thursday, February 13, 2003, at 05:44 PM, Oleg Kalnichevski wrote:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: java/org/apache/commons/httpclient
Changelog:
- In non-strict mode each cookie sent with the request is put on a
separate request header.
- In strict mode all cookies are crammed into one request header, as
before
The patch requires the test webapp to be recompiled redeployed
It's a fairly minor change blessed by Jandalf long
Hi Yang
Could you please execute your application with the following system
properties
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
-Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug
Mike
I see no file attached. Try posting it one more time. I'll be happy to
check it in
Oleg
On Tue, 2003-02-18 at 16:09, Michael Becke wrote:
Attached is a patch that updates two of the examples. The following
has changed:
- examples now compile in 1.3.1
- some layout changes have
I have just committed the patch. Please recompile redeploy test web
application (httpclienttest) in order to avoid test-case failures. I
apologize for inconveniences caused.
Regards
Oleg
On Mon, 2003-02-17 at 21:00, Oleg Kalnichevski wrote:
Changelog:
- In non-strict mode each cookie sent
Laurent
HttpClient 2.0a2 has been released with a few bugs related to content
encoding in HTTP POST PUT methods. They have been fixed in the current
version. Give the nightly build of HttpClient a try. If the problem
persists please let me know
Cheers
Oleg
On Tue, 2003-02-18 at 17:00, Laurent
Hi Vincent
HTTP spec defines two types of encoding: HTTP element encoding content
encoding. HTTP elements such as request line, status line,
request/response headers must be hard-coded in US-ASCII.
Request/response content encoding is not hard-coded and can be specified
by the HTTP agent by
Adrian (and all)
I agree that with you about keeping HttpClient JVM independent and
reasonably generic. Clearly proxy detection should be kept outside
HttpClient package IMHO.
But you know what? Maybe HttpClient have matured well enough so that we
have reached the point where we should start
+1
And that is a VERY BIG PLUS ONE from me
Oleg
On Wed, 2003-02-19 at 18:28, Jeffrey Dever wrote:
Mike Becke has been an active contributor for many months. He has
worked on a diverse range of problems with high quality results. He has
been consistant, reliable, helpful and open to
Oleg Kalnichevski wrote:
Adrian (and all)
I agree that with you about keeping HttpClient JVM independent and
reasonably generic. Clearly proxy detection should be kept outside
HttpClient package IMHO.
But you know what? Maybe HttpClient have matured well enough so that we
have
, 2003-02-20 at 17:04, Sam Maloney wrote:
On Wednesday 19 February 2003 17:39, Oleg Kalnichevski wrote:
Hi Sam
I believe the bug has been fixed by now. I stumbled upon it a few days
ago pretty much by chance
http://www.mail-archive.com/commons-httpclient-dev%40jakarta.apache.org/msg
Committed
On Thu, 2003-02-20 at 17:32, Jeffrey Dever wrote:
Oleg, this fix will need to go in before we drop alpha3.
Sam Maloney wrote:
On Wednesday 19 February 2003 17:39, Oleg Kalnichevski wrote:
Hi Sam
I believe the bug has been fixed by now. I stumbled upon it a few days
ago
Folks
I was going to start working on it today. If there are any other takers,
please let me know
Cheers
Oleg
On Mon, 2003-02-24 at 07:27, Jeffrey Dever wrote:
This is currently on the todo list. Refer to the following bug for more
information:
;
+import org.apache.commons.logging.LogFactory;
+
+/**
+ * Logs data to the wire LOG.
+ *
+ * author a href=mailto:[EMAIL PROTECTED]Oleg Kalnichevski/a
+ *
+ * since 2.0beta1
+ */
+
+public class Wire {
+
+/** Log for any wire messages. */
+private static final Log WIRE_LOG = LogFactory.getLog
Jeff,
The commons-loggign.jar file appears corrupt. Am I the only one
experiencing this problem?
Oleg
On Mon, 2003-02-24 at 16:20, Jeffrey Dever wrote:
Ok, new rc2 package available:
http://jakarta.apache.org/builds/jakarta-commons/release/commons-httpclient/v2.0
Michael Becke wrote:
Martin
That's the way things are done in all Jakarta sub-projects. I am afraid
we have to conform
Cheers
Oleg
On Mon, 2003-02-24 at 20:12, Martin Cooper wrote:
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Monday, February 24, 2003 8:05 AM
To: Commons
On Tue, 2003-02-25 at 04:08, Michael Becke wrote:
One problem. The change made earlier today to
HttpClient.executeMethod() is a killer for the
MultiThreadedHttpConnectionManager. It releases all connections before
they are used in a method. I should have complained more loudly about
Simon
I'd really appreciate it if you could send us the debug trace for
analysis. Please refer to the following url for instructions on how wire
log can be activated:
http://jakarta.apache.org/commons/httpclient/logging.html
Your problem should be easily solvable by disabling 100-continue
ethodBase.java:2377)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:963
)
I'll try disabling the feature as you said, see what happens.
Oleg Kalnichevski a écrit :
Simon
I'd really appreciate it if you could send us the debug trace for
analysis
into it sometime.
What you say is weird, I have another line where my post went ok :
Oleg Kalnichevski a écrit :
Aurelien
This is the expected behavior with non-compliant HTTP servers. The
HTTP server apparently does not respond with 100-continue as expected.
HttpClient resumes sending
* author a href=mailto:[EMAIL PROTECTED]Michael Becke/a
* author a href=mailto:[EMAIL PROTECTED]Mike Bowler/a
* author Sam Maloney
+ * author a href=mailto:[EMAIL PROTECTED]Oleg Kalnichevski/a
*
* version $Revision: 1.69 $ $Date: 2003/02/21 13:48:09 $
*/
-97,6 +102,9
/** Log
Simon
Please try these settings. This should prompt commons-logging to use
SimpleLog instead of Log4J, which does not support TRACE verbosity.
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
-Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug
would definatly agree on your point that 'Client' logic should be in
HttpClient and not in HttpMethodBase. (I would say redirect, auth and even
auto-retry would count as 'Client' logic).
Sam
On Tuesday 25 February 2003 15:27, Oleg Kalnichevski wrote:
Folks
I am currently working
handling I would
suggest removing the use of the URL class. I think URI is better suited
for this purpose. Also, using URL could be a problem with custom
protocol types.
Mike
Oleg Kalnichevski wrote:
Folks
I am currently working on a patch enabling HttpClient to handle
cross-site
Folks
Any feedback on this one. Can interpret absence of responses as silent
approval ;-)
Cheers
Oleg
On Mon, 2003-02-24 at 14:02, Oleg Kalnichevski wrote:
I hope it works this time around
Oleg
On Thu, 2003-02-13 at 07:30, Jeffrey Dever wrote:
Haven't had time to review all
other regards.
I get the same problem with HTTP PUT.
Adding
method.setUseExpectHeader(false);
seems to fix it.
Cheers, Simon
- Original Message -
From: Oleg Kalnichevski [EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED
in the
first place.
Jandalf.
Oleg Kalnichevski wrote:
Hi Laura
On Wed, 2003-02-26 at 00:24, Laura Werner wrote:
Hi Oleg,
Please remember those of us who aren't using the HttpClient class right
now because it isn't quite flexible enough. If all of the redirect and
authentication
1 - 100 of 1775 matches
Mail list logo
