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
Zulfi Umrani wrote:
I will appreciate if anyone answers my questions below.
-Does anyone has perfromance comparison between HTTPClient and JDK
HttpURLConnection?
I remember there was a comment about that on the list some months ago.
The guy said that HttpClient was slightly faster than
Good to here that you are fine! Welcome back to the Fellowship of The
Protocol. I have been missing your insightful comments on the list recently.
Odi
Jandalf wrote:
My house has sold, I've moved to Calgary and I have a new job. All is
well. I've been monitoring the list and have been taking
Molina, Teresa wrote:
I'm experiencing a problem with the response code (and body) returned after
HttpClient tries to execute a (get) method on an unknown host. If the host
had previously been in DNS and returned a valid (200, eg) response code,
subsequent attempts to execute still return that
[EMAIL PROTECTED] wrote:
I am looking for a way to specify a particular
client SSL certificate for Client Authenticated SSL.
This is usually done by writing a SSLSocketFactory that creates Sockets
with the Client Cert attached.
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
Laura Werner wrote:
There shouldn't be any obstacles in your way to implement caching.
It depends on what you want the cache's API to look like. I've been
meaning to post about this lately, so here goes
Ideally, I'd want the API for executing an HTTP method via the cache to
look almost
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. The whole issue seems
still a bit unclear to me, but
Odi,
Laura eventually conceded that these methods did not seem to make a lot of sense or
were too specialized to be of any use for the majority of the HttpClient users.
http://marc.theaimsgroup.com/?l=httpclient-commons-devm=104577672115772w=2
I do think that releasing HttpClient with stuff
All,
Personally, I believe that this issue has gone on far too long and so I
would like to propose a vote:
I move the motion that the following methods from
org.apache.commons.httpclient.util.URIUtil be depreciated for the 2.0
release and removed in a future release:
+1
Adrian Sutton wrote:
I move the motion that the following methods from
org.apache.commons.httpclient.util.URIUtil be depreciated for the 2.0
release and removed in a future release:
toDocumentCharset(String)
toDocumentCharset(String, String)
toProtocolCharset(String)
+1
-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Thu 6/26/2003 11:10
To: Commons HttpClient Project
Cc:
Subject:[VOTE] Re: 2.0 release
All,
Personally, I believe that this issue has gone on far too long and so I
would like to propose a
-1
My vote... :D
FYI, (it's from URI javadoc messages, I think they are related to your
topic.)
[snip]
* The character set used to store files SHALL remain a local decision
and
* MAY depend on the capability of local operating systems. Prior to the
* exchange of URIs they
Sung-Gu wrote:
I've made sample cases and posted it before. (even if it's not a normal
junit testcase though.)
And I'm not willing to make testcase for that. I'm not interested in unicode
values... at all...
Sung-Gu,
I there are no test cases, how can we be sure these methods do what they
are
Hey Jeff,
Welcome back! I'm glad that everything has worked out.
Mike
On Thursday, June 26, 2003, at 12:39 AM, Jandalf wrote:
Hello all!
My house has sold, I've moved to Calgary and I have a new job. All is
well. I've been monitoring the list and have been taking care of the
moderate
+1
On Thursday, June 26, 2003, at 05:10 AM, Adrian Sutton wrote:
All,
Personally, I believe that this issue has gone on far too long and so
I would like to propose a vote:
I move the motion that the following methods from
org.apache.commons.httpclient.util.URIUtil be depreciated for the 2.0
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
are supposed to do? I find it dangerous to have code that nobody
Ok, Sorry, then as you wish, I'll change my vote +1.
I hope you're happy...
understands (except of you) without any test cases.
Actually, I don't understand
Ortwin -
Correct. I have completed the code using javax.net.ssl.HttpsURLConnection
(Creating a special keymanager (for my crypto framework), setting up the
SSLContext, creating SSLSocketFactory, etc.) . I was just hoping that
HttpClient had a Socket factory already written for this
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
Adrian,
+1
OK, my vote is non-binding, but with no test cases, and no code in
HttpClient that uses the functions, we SHOULD deprecate them.
Even if we decide later, as Sung-Gu suggested, that we might need to
ressurrect them, we should still deprecate them! Deprecating them is a
flag for
- Original Message -
From: Adrian Sutton [EMAIL PROTECTED]
If you don't know why the code would be useful or what it was
implemented based upon, why is it that you still want it in HttpClient?
There is nothing that uses those methods anywhere in HttpClient and
the presence of an
- Original Message -
From: Eric Johnson [EMAIL PROTECTED]
Even if we decide later, as Sung-Gu suggested, that we might need to
ressurrect them, we should still deprecate them! Deprecating them is a
Done.
Sung-Gu
+1
As these methods are not used by HttpClient and do not appear useful for
httpclient for httpclient users combined with the reality that they do
not appear correct and the pending desire to start a Commons-URI project
indicates that they should not be in the public interface of HttpClient.
Adrian Sutton wrote:
The flaw in the toUsingCharset method is two-fold:
Firstly, Strings in Java are *always* stored internally as UTF-8
I agree with the rest of your analysis of this, but I thought I should
point out that Java Strings and chars are stored in UTF-16 rather than
UTF-8. A char
Mike,
Thanks for starting this discussion. I've been contemplating this one
for a while.
My development approach follows along the lines of revolution through
evolution. Which means, with respect to HttpClient, that on the one
hand I don't want to encourage too many fundamental changes for
Sorry if this is the wrong place to ask this question, but where is the
proper place to post user questions about HttpClient? Couldn't find a user
mailing list.
--Nathan McMinn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
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
Adrian,
I attached the title like the above. ;)
Please see some comment the below step 1-0 and 1-1.
Hope to be helpful for the furture,
Sung-Gu
- Original Message -
From: Sung-Gu [EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 10:39 PM
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
It sure would be useful however I am not sure if it is possible. I never
used a standard JSSE implementation. We used SSLava in our projects
(because it's supposed to be faster) and SSLava is does not have a JSSE
interface. So I wrote a SSLSocketFactory that configured SSLava to use a
specific
Sung-Gu wrote:
But, not a duty... it's voluteering... no pay...
even the code constribution here...
I pay you $5 for test cases from my Paypal account. Promise.
:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Thank you. It's kind of an http newbie question, but here it is. I create
a PostMethod object, and use it to post data to a site's login page. The
login page redirects to another page within the site. When that redirect is
sent, I get the following message:
Jun 26, 2003 1:48:21 PM
Hi Nate,
Jun 26, 2003 1:48:21 PM org.apache.commons.httpclient.HttpMethodBase
processRedirectResponse
INFO: Redirect requested but followRedirects is disabled
...
I can just create a GetMethod and give it the url that would be redirected
to, but how to get rid of that error message. Any
Perfect. Thanks.
- Original Message -
From: Laura Werner [EMAIL PROTECTED]
To: Commons HttpClient Project [EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 2:47 PM
Subject: Re: Where to post
Hi Nate,
Jun 26, 2003 1:48:21 PM org.apache.commons.httpclient.HttpMethodBase
This doesn't look correct, if you are really wanting to convert
from one charset to another then you would have to do something
such as:
String myString = new String(bytes,bytesCharset);
byte[] bytes2 = myString.getBytes(destCharset);
Until you have the bytes, you don't have the final
Make MultiThreadedHttpConnectionManager defaults public statics.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21130.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
Make MultiThreadedHttpConnectionManager defaults public statics.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21130.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
I just got through Internationalizing a website... input and output. I
ran into the exact same issues, and as Andre states, you pretty much need
to check everywhere for byte[] -String and String-byte[].
Then do the conversions he's given. I personally liked the more terse:
byte[]
It is possible to create a standard JSSE impl, but only for 1.4 JDK. In
previous JDK's the required classes were of the com.sun.net.ssl variety,
which of course is ugly. There is no cross-vm solution for JDKs prior to
1.4 that I am aware of.
- Matt Secoske
Ortwin Glück [EMAIL
On Thu, 2003-06-26 at 23:40, [EMAIL PROTECTED] wrote:
I just got through Internationalizing a website... input and output. I
ran into the exact same issues, and as Andre states, you pretty much need
to check everywhere for byte[] -String and String-byte[].
Matt, we actually do. We do have
Does any one know how can I manage cookies without having to get the
cookies from HttpState and setting it back everytime I make a request?
Is there an automatic way to handle cookies? Alternatively, how do I put
a cookie header on PostMethod? I have string representation of the
cookie, I would
Is there an automatic way to handle cookies?
According to whatever less I know about HttpClient, this is the default
behavior. Cookies are handled automatically. If you put the logging on
as given on the link
http://jakarta.apache.org/commons/httpclient/logging.html you will see
some entries like
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21130.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I enable the logging for info, but did not get any message on the
console. And the cookies still are not handled automatically.
[EMAIL PROTECTED] 6/26/2003 9:17:57 PM
Is there an automatic way to handle cookies?
According to whatever less I know about HttpClient, this is the
default
behavior.
This doesn't look correct, if you are really wanting to convert
from one charset to another then you would have to do something
such as:
String myString = new String(bytes,bytesCharset);
byte[] bytes2 = myString.getBytes(destCharset);
Until you have the bytes, you don't have the final
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21130.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
To see the network traffic you will need to enable the wire log. Take
a look at http://jakarta.apache.org/commons/httpclient/logging.html for
details.
HttpClient handles cookies by default. For more details please see
http://jakarta.apache.org/commons/httpclient/cookies.html. If the
cookie
47 matches
Mail list logo
