-codec as an HttpClient dependency
oops, true. No idea why I remembered only two classes...
Kalnichevski, Oleg wrote:
Odi,
I do not think it is quite correct. There's now at least two dozens of files, and
some of them are really of marginal use (language and phonetic encoders, for
instance
True, but neither has HttpClient 2.1:) We will most likely have to put
some effort into getting a final codec release that contains this code.
I agree, adding a jar could be considered an API break, but it was part
of our plan for 2.1. The only real API changes that this requires is
, but I finally want to be
able to do things right
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 16:26
To: Commons HttpClient Project
Subject: Re: [VOTE] Add commons-codec as an HttpClient dependency
Kalnichevski, Oleg wrote:
Right
I guess you are right. It is mostly a case of semantics. What exactly
do we mean by 2.1? The official description of a minor release does not
really fit with our plans (which I still agree with). I do not think a
3.0 release is quite appropriate either though. Is there a middle
)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:500)
at com.mypackage.myclass.mymethod(myclass.java:140)
--- Kalnichevski, Oleg
[EMAIL PROTECTED] wrote:
Can you also enable debug logging for HttpClient
classes by doing the following?
log4j.logger.org.apache.commons.httpclient=DEBUG
Mike,
It looks like out recent patch is still not quite correct in handling multiple
transfer encodings. I have re-read the relevant sections of the RFC 2616 on this issue
and found out the following:
Multiple transfer encodings are not supposed to be declared in separate
'Transfer-Encoding'
14.41 Transfer-Encoding
...
Transfer-Encoding = Transfer-Encoding : 1#transfer-coding
...
2.1 Augmented BNF
...
#rule
A construct # is defined, similar to *, for defining lists of
elements. The full form is n#melement indicating at least
n and at most m elements, each
I must be getting paranoid ;-) You are right, as those methods are protected, that
should not be an issue.
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Tue 7/8/2003 15:34
To: Commons HttpClient Project
Cc:
Subject:Re: DO NOT REPLY
Christopher,
this thread has gotten a bit out of hand now...
As long as we manage behaving as mature people, I see no problem in talking things
through
offensive, implying that we're doing something weird by using CVS HEAD
of HttpClient (which is totally normal at Jakarta). And your
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: July 3, 2003 10:42 AM
To: Commons HttpClient Project
Subject: RE: Is HttpClient supported by non-Sun VMs?
Robert,
If my memory does not fail me, IE is shipped with Microsoft JVM 1.1.4.
HttpClient requires a Java 2
All,
I have taken the liberty of compiling a draft 2.1 release plan that incorporates
various ideas tossed around recently (special thanks go to Eric Johnson). I feel we
ought to clearly articulate our short- to mid-term development plans before 2.0 goes
RC1.
Comments, ideas, critique welcome
To: Commons HttpClient Project
Cc:
Subject:RE: Continue - 100
Hi !
I am already using the BETA-1 and the 100-continue error continues.
What should I do ?
Thanks
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Friday, June 27, 2003 11:36 AM
Upgrade to BETA-1 or current CVS snapshot. I suppose you are using on of the ALPHA
releases, as since BETA-1 HttpClient never returns 100 (continue) status code to the
caller.
http://jakarta.apache.org/commons/httpclient/downloads.html
Cheers
Oleg
-Original Message-
From: George
Is it safe? Is it secret?
I knew it would happen. Welcome back. You have been missed
Oleg
-Original Message-
From: Jandalf [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 06:40
To: Commons HttpClient Project
Subject: Poof!
Hello all!
My house has sold, I've moved to Calgary
Jandalf,
Beta-1 release surprisingly revealed very few bugs. None of those few was serious. It
looks like we did a pretty good job during late Alpha3 eradicating most serious bugs.
I believe HttpClient can now be considered feature and documentation complete. I agree
with Adrian that what we
HttpClient Project
Cc:
Subject:Re: 2.0 release
Kalnichevski, Oleg wrote:
I have only one outstanding issue on my hands: deprecation of
URIUtil.toXXXCharset methods.
As far as I remember these methods are not currently used. So they do
not harm. We can address this later if necessary
or the proposal will be turned down if there are any -1 votes.
I would encourage non-committers to submit non-binding votes as well,
particularly if you can see a use for the methods in question.
Here's my +1.
Regards,
Adrian Sutton.
On Thursday, June 26, 2003, at 06:25 PM, Kalnichevski, Oleg wrote
Actually, I don't understand that you might notice and you might wonder
why there is encoding change menu in your web browser. and you can
test it yourself though.
Knock, knock. Hello, anybody home? Half a year ago, when this whole story started I
tried to explain you one simple thing: in
Eric,
Fantastic proposal that I whole-heartedly support. Let me present my own more
condensed version with a few omissions (that are not critical at all)
2.1 release:
- Better exception handling framework (bug #19868)
- Cross-site redirect fix. Authentication, redirect retry code moved from
Nathan,
Please go ahead and post your questions here, as there's no separate HttpClient user
mailing list.
Oleg
-Original Message-
From: Nate [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 16:59
To: [EMAIL PROTECTED]
Subject: Where to post
Sorry if this is the wrong place to
Folks,
I have just finished the first draft of the URL codec and submitted it to the Commons
Codec people for review as the following feature request:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21053
Please let me know what you think. Feel free to submit variations of my patch if you
Hmm... looks like... most're intersted in some uri encoding methods. (at
least in the mailing list)
However, I will say that URI is generally a parser for some purposes with
having some coder feature.
As I look into Commons-Codec, well... bula...bula...
And I think it's not a right choice.
Colin,
DIGEST authentication works fine with Apache 2.0 (I just tested it) and *should* work
with IIS. Please note that the server returns status code 500 which means internal
server error, not an authentication error.
In order to pinpoint the problem, we'll need a bit of help from your side.
Yep. Static variables should be in upper case. Will be done.
Oleg
-Original Message-
From: Ortwin Glck [mailto:[EMAIL PROTECTED]
Sent: Thu 6/19/2003 17:03
To: Commons HttpClient Project
Cc:
Subject:Re: DO NOT REPLY [Bug 20481] - HttpClient does not properly
Eric,
I would rather keep web.xml file parsing out. We have to maintain compatibility with
Java 1.2.2 for which JAXP is an optional component. I do not think we should introduce
JAXP as a dependency for HttpClient.
Oleg
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Hi Sung-Gu,
long time, no see, indeed.
Have you spoken with any of the Jakarta Commons management folks regarding spinning
URI support into a Commons sub-project of its own?
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Ralph and the HttpClient folks out there
Initially I thought that HttpState class should have been made serializeable per
default. Later I realized that there was a catch, however. The HttpState class besides
cookies also contains credentials for target servers and proxy servers. From the
Dan,
That would definitely be a bug. However, it would be too obvious and too massive a bug
to be so easily overlooked by the time of beta-1. Would it be possible to provide us
with the wire log of the HTTP session that exhibits the problem? Meanwhile, I will
walk through cookie management code
Manuel,
We have discovered that HttpClient does not properly handle 'x-www-form-urlencoded'
encoding. The problems with POST requests you have been experiencing appear to have
been caused by this bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20481
I'll be working on a fix. Stay tuned
Hi Rainer
I am one of the Apache Jakarta Commons HttpClient developers.
http://jakarta.apache.org/commons/httpclient/index.html
I have stumbled upon your post on Sun's Java Technology Forums pretty much by chance.
As far as I understand you have been working on a HttpURLConnection
Zulfi,
Try setting both realm host to null. That should do the trick
HttpClient hc = new HttpClient();
HttpState state = hc.getState();
state.setAuthenticationPreemptive(true);
// Set default credentials (realm host are null)
state.setCredentials(null,
Jay,
The only solution that I can think of is to get hold of HttpClient source code and
extend it with a feedback mechanism of your liking. We, HttpClient developers, may
consider adding events in 2.1 or 3.0 release as a standard feature. For the time
being, a HttpClient fork appears your only
must the body of a post request be encoded as a URL Query?
Yes, it must, when the post body content is specified as a set of name/value pairs.
For more details you may refer to
http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1
One can still provide a raw post body and a custom
for details
Oleg
-Original Message-
From: Zulfi Umrani [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 17:03
To: Kalnichevski, Oleg; [EMAIL PROTECTED]
Subject: RE: preemptive
What do you mean by eliminating the authentication overhead? Does this
mean keeping the already Authenticated
Folks
I have just finished writing the first draft of what it is eventually going to be the
SSL Guide. As far as I am concerned the SSL Guide appears pretty much the last missing
piece of documentation. Is there anything else you may want documented? Do you think
any of the existing documents
George,
Please note that HttpConnection.ConnectionTimeoutException represents a connection
timeout (set with HttpClient#setConnectionTimeout), not a read timeout (set with
HttpClient#setTimeout). Can it be that this confusion is the source of the problem?
Oleg
-Original Message-
From:
(). The defaults for
soTimeout and connectionTimeout are both 0.
Mike
Kalnichevski, Oleg wrote:
Well, after having browsed through the source code, I am afraid the
answer is 'undefined'. HttpConnection class invokes
socketFactory#createSocket method, which in its turn calls
Socket#Socket constructor, which
Jan,
Let me elaborate. No doubt one can still do silly things in Java that may lead to
severe memory problems. However, the point I was trying to make is that Java
applications do not 'leak' memory in a way non-GC applications do. One can easily
starve a java application of heap memory if
Folks
Beta-1 has been tagged on the CVS trunk two days ago and is officially out. The
problem is that we are unable to deploy the official build without Jeff Jandalf, our
project lead, as only he has necessary access permissions for the official Jakarta
file repository web site.
You can
Sunil,
'Set-Cookie: DOMS=; PATH=' cookie is rejected as it violates the RFC2109 specification.
Here's what you should do to work the problem around:
1) Upgrade to the latest nightly build (commons-httpclient-20030527.tar.gz)
Om,
I strongly recommend to upgrade to beta-1 release (currently available through CVS
only) or the latest nightly build. As far as I can see from the trace log you are
still running an old version (most probably 2.0a3)
I'll be working on an SSL guide this weekend. So, stay tuned
Oleg
Mike,
Beta-1 release next weekend of following week would be great. How much work does
MultiThreadedConnectionManager still require? Would one week be enough? I'll try to
deal with virtual hosts issue meanwhile. Anyways, we can't release with Jandalf still
missing. He wrote he was going to be
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 2:50 AM
To: Commons HttpClient Project
Subject: RE: POST, Expect-100 and 401 Problem
Joe,
Please help me understand what is exactly the problem. The whole idea of
using 'expect: 100-continue
Andre,
1) SSL
HttpClient is reliant upon Sun's JSSE implementation (alternative SSL implementation
can also be plugged-in with a bit of coding) to provide SSL transport encryption. From
the HttpClient's standpoint HTTP does not differ much from HTTPS (if at all) once
communication socket has
2003 16:42
To: 'Commons HttpClient Project'
Subject: RE: POST, Expect-100 and 401 Problem
The upgrade to the nightly build fixed it.
Thanks,
Joe
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 9:14 AM
To: Commons HttpClient Project
Andre
Recently there has been an SSL vulnerability discovered related (very roughly put) to
the time it takes the server respond to an invalid authentication request. For more
details refer to
http://lasecwww.epfl.ch/memo_ssl.shtml
I would not be too surprised if newer SSL implementation
? Is the server sending me this anyway, or the
httpclient is sending the header Expect 100: continue with my post data?
Best regards,
Andre
-Original Message-
From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Sent: quinta-feira, 3 de abril de 2003 12:14
To: Commons HttpClient Project
Hi Padraig
I am glad you have gotten a handle on this problem. I suppose older versions of
WebLogic HTTP server have issues with chunk-encoding content. This is exactly the case
when 'Content-Length' header MUST NOT be sent to the server according to the HTTP/1.1
spec. Under all other
Hi Mike,
is there a need for someone to supply their own AuthScheme? it
seems that all of the choices are now hard coded.
I am perfectly aware of limitations of the current design in this regard. Clearly,
adding custom authentication schemes or extending/customizing existing ones should be
Hi Thiago
I regret that your message has been ignored for so long.
1. connection timeouts are perfectly legitimate from the HTTP spec standpoint. HTTP
servers are not supposed to keep connection alive for too long. Probably HttpClient
should be a bit smarter when encountering a stale
Hi Max,
We do not have such an example available. This is as close as it gets:
http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/contrib/org/apache/commons/httpclient/contrib/ssl/
EasyX509TrustManager.java EasySSLProtocolSocketFactory.java classes extend standard
SSL classes in
Sergio
Do not forget that these days people tend to use HTTP protocol for all sorts of things
which it has never been envisaged for. HTTP has never been designed to support
transactions. HTTP has been designed to support browsing porno-sites (quoting Don Box
of Microsoft) There's always a risk
Thomas
The web server reported as Apache/1.3.19 (Unix) (SuSE/Linux) mod_ssl/2.8.3
OpenSSL/0.9.6a mod_perl/1.25 fails to respond to the GET request at all. HttpClient
hangs while waiting for a response status line.
2003/03/26 09:25:37:661 CET [TRACE] HttpMethod - -enter
for the
client because it hangs forever. Is there a possibility to set a timeout?
-Ursprüngliche Nachricht-
Von: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 26. März 2003 10:42
An: Commons HttpClient Project
Betreff: RE: HttpClient contrib package established
Thomas
The web
Hi Chris
As far as your first point is concerned, just bear with us for a short while. I am
currently working on a patch that should address the problem.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17884
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17158
As far as your second point
in the following form: '[EMAIL PROTECTED]'. If no credentials are returned,
another attempt should be made using 'realm' only
Folks, let me know what you think.
Cheers
Oleg
Credentials map
-Original Message-
From: Kalnichevski, Oleg
Sent: Freitag, 21. März 2003 16:21
To: Commons HttpClient
Mike, inline patches never work with me :-( My e-mail client renders them invalid,
probably by wrapping lines or something.
As far I can judge, the patch does reasonable things. I suggest that you just go ahead
and commit it
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL
Sylwester
= HttpClient adds default 'User-Agent' header only in case the header has been
explicitly given by the user
GetMethod httpget = new GetMethod(http://whatever.com/;);
httpget.setRequestHeader(User-Agent, Whatever-agent);
= By specifying -Dhttpclient.useragent=whatever-agent system
Tom
Thanks for pointing it out
Cheers
Oleg
-Original Message-
From: Tom Samplonius [mailto:[EMAIL PROTECTED]
Sent: Freitag, 14. März 2003 08:06
To: Commons HttpClient Project
Subject: RE: problem with post
On Thu, 13 Mar 2003 [EMAIL PROTECTED] wrote:
System.setProperty(
Vikram
Now it is clear as day light, that the web server you are posting requests to does not
support (or does not correctly implement) 'Expect: 100-continue' handshake.
1) What web server are you using? Does the server support HTTP/1.1?
2) Follow the instructions from my previous post to work
Fredrik,
We have striven to make transfer encoding absolutely transparent to the client. We
have never envisaged direct access to individual chunks of chunk-encoded data.
I may be wrong here, but let me express my personal opinion on this matter. Please
bear in mind HTTP protocol has been
Hi Gourav
The trace does not tell me much. What I can gather from it is that it is quite likely
that your web server may have issues with HTTP/1.1 protocol. Try setting HttpClient to
use HTTP/1.0 instead. If I recall right, you use HTTP/1.0 when posing requests using a
raw socket
PostMethod
Thomas
What do you mean by an empty FilePart? A zero-length file? As always, a test case
would greatly simplify my task of tracking down the bug
Cheers
Oleg
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 11. März 2003 13:59
To: [EMAIL PROTECTED]
Folks,
There are currently three outstanding patches in the bugzilla. I am currently working
on a few more, so I expect patches to keep on piling up. Any feedback on the
outstanding patches (be it negative or positive) would be really great
Cheers
Oleg
Gourav,
I just concatenated RFC 2616 six times and posted the resulting file (2.5 MB) to an
'echo' servlet running on Tomcat 4.1.18 using PostXML demo application. The response
came back almost instantaneously and overall process including printing out the
response body to the console under
Jandalf,
Just to make sure I got you right: both
getResponseContentLength()/getRequestContentLength() methods should be added to the
HttpMethod interface?
Cheers
Oleg
-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 11. März 2003 16:32
To: Commons
+1
I am glad the patch will also eliminate tight coupling between HttpMethodBase
ConnectMethod
Cheers
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 03:41
To: Commons Project
Subject: patch comments
Are there any comment for or
Hi Adrian
1. URLs should only consist of ISO-8859-1 characters whenever possible as
this is the encoding used by RFC 1738 and using other encodings may cause
compatibility issues with some servers (eg: Windows Web Folders). This is
mostly due to the fact that there is no way to determine the
Can anyone shed some light upon the status of this bug? It's been marked as critical,
yet I see no one rushing to fix it. The problems seem to be better addressed by
Sung-Gu due to his speciality in URI encoding related stuff but since he has not
been showing up much recently, someone needs to
Hi Padraig
Makes sense to me. If no one loudly objects, I'll apply the patch by Monday the latest
(or shall I say monday? ;-))
Cheers
Oleg
-Original Message-
From: Padraig O'hIceadha [mailto:[EMAIL PROTECTED]
Sent: Freitag, 7. März 2003 16:00
To: [EMAIL PROTECTED]
Subject: [PATCH]
David
HttpClient is a library, whereas a browser is a totally different kind of beast.
RFC 2616 says the following:
...
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be
!
Regards,
David
Kalnichevski, Oleg wrote:
David
HttpClient is a library, whereas a browser is a totally different kind of beast.
RFC 2616 says the following:
...
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically
Mike
This is massive!!! It's a much needed and welcome refactoring. Many thanks for this
work
Oleg
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 5. März 2003 05:34
To: Commons Project
Subject: cvs commit:
code. I will post some
ideas before I get to work. Please let me know if you have any ideas
about how we can improve our tests.
Thanks,
Mike
On Wednesday, March 5, 2003, at 03:39 AM, Kalnichevski, Oleg wrote:
Mike
This is massive!!! It's a much needed and welcome refactoring. Many
thanks
Juergen
I have tried my best to reproduce the alleged bug in my development environment
(which, I have to say, does not include Jakarta-Slide). Please see the test cases I
have used. It's been run with the following system properties to generate the
following dump
Jandalf
Got ya. I have just managed to reproduce the behaviour of buggy servers that ignore
Expect: 100-continue header and discovered BIG FAT NASTY bugs in my code. So, I am
currently busy busting those bugs. I'll proceed implementing your suggestions once all
bugs are dealt with. I'll look
The bugs turned out to be not of my making. There are too many spots in the
HttpMethodBase class and its derivatives where statusLine is blindly assumed to be
always non-null.
Cheers
Oleg
-Original Message-
From: Kalnichevski, Oleg
Sent: Freitag, 31. Januar 2003 17:03
To: Commons
301 - 377 of 377 matches
Mail list logo
