RE: [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.

[Aurelien Pernoud]

I'll give a try to current CVS today. Thx

BTW, even if it doesn't count, +1 for mike :)

Jeffrey Dever a ecrit :

> Patch committed.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17166] - HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17166

HttpClient does not compile 'out of the box' in IBM's VisualAge IDE





--- Additional Comments From [EMAIL PROTECTED]  2003-02-20 03:22 ---
David,
You will need to provide your own patch for this.  The current cvs HEAD builds
fine with jdk1.2.2 (still 3 tests failing) and j2sdk1.4.1.  I don't have
VisualAge, only Eclipse and Sun runtimes so can't test any patch either but will
take your word for it as long as jdk1.2.2 and j2sdk1.4.1 are still OK.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10809] - Developer documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809

Developer documentation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2003-02-20 03:07 ---
Please don't redeploy the site just yet (commiting the files is optional) as I 
need to create a few more files to satisfy the index yet.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10809] - Developer documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809

Developer documentation





--- Additional Comments From [EMAIL PROTECTED]  2003-02-20 03:05 ---
Created an attachment (id=4935)
Updated authentication guide and rearranged side menu to pave the way for the extra 
documentation to be added.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10809] - Developer documentation

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10809

Developer documentation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|commons-httpclient- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|ASSIGNED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2003-02-20 03:01 ---
This looks like what I'm working on, so reassigning to myself.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

2.0 alpha 3 pending release

[Jeffrey Dever]

We were going to do a intermediate alpha release last weekend but was 
held up.  I would like to go ahead with that again.  There have been 
some notable fixes since alpha2, and some mistakes in the build process 
(like releasing 1.4.1 built classes).

So, unless there are any gating problems, I would like to code freeze 
now, spend a day or so doing cleanups, and then drop the 2.0 alpha 3 
release Friday morning.

Jandalf.
HttpClient 2.0 release prime


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Fix for bug 16458

[Jeffrey Dever]

In a very large project I am a senior on, I use to be using HTTPClient v0.3-3 
(www.innovation.ch/java/HTTPClient/).

b) After looking at the code to try to fix the problem, not only did I give up 
trying to fix the problem, but I also gave up on the product :)
 

Yes, I went through exactly the same process.  I needed preemptive 
authorization which turned out  to be a nightmare to add to the 
innovation HTTPClient but oh so easy to add to Jakarta HttpClient.

I want to point out that I encountered bug 13463 early on, and after reading 
the bugzilla db, I tried the patch attached to the end of it. I would just 
like to give my vote to include it into CVS, as it fixes the problem (bug 
13463) perfectly.

Its a pretty good sign when you start using a new product and they 
already have fixes for some of the bugs you find!  The development team 
here working on HttpClient is better than any other team I have been 
involved with in my corporate life.

As for bug 16458, I have fixed it.

It was a rather simple bug, and can be reproduced by closing the server side 
socket while the client is still waiting for a response. This will cause the 
client to take 100% cpu, and it will do so for ever and ever.

 

Its great you made that connection which would have gone unnoticed.  I 
would probablly have had to mark that bug as "works for me" otherwise as 
it was apparently inadvertently fixed.

I have another bugfix that I will post in my next message.

 

Looking forward to it.

Jandalf
HttpClient release prime.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Bug 13463] - Request/Response race condition when doing multiplerequests on the same connection.

[Jeffrey Dever]

Patch committed.

Aurelien Pernoud wrote:


10 users using 5 requests (no cache implemented for this test), I have some
recoverable exception, but no errors at all !

Nice work ;)

I'll try it later on a real server with more users cause here I was limited
with total connections allowed by my OS and Tomcat.

Michael Becke a ecrit :

 

Sounds good.  Thank you for putting all of this work into testing.

Mike
   



-
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]

DO NOT REPLY [Bug 13463] - Request/Response race condition when doing multiple requests on the same connection.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13463

Request/Response race condition when doing multiple requests on the same connection.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||commons-httpclient-
   ||[EMAIL PROTECTED]
 AssignedTo|commons-httpclient- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |



--- Additional Comments From [EMAIL PROTECTED]  2003-02-20 01:06 ---
Patch committed.  Please retest and close.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proxy-Connection: close header

[Laura Werner]

Adrian Sutton wrote:


Do you have any idea how to make squid use that header?


I don't think we're doing anything special to make it happen.  Here are 
the headers from a couple of typical transaction, with a few host names 
slightly obscured.  This is using my own Java-based caching code on top 
of httpclient alpha 1.  (I'm starting to upgrade to the latest version now).

Try to fetch a resource from a machine the Squid proxy doesn't have 
access to:
16:49:30:311
HTTP request headers for jack.vxml:
   Host: privatemachine.bevocal.com
   User-Agent: BeVocal/2.4 VoiceXML/2.0 BVPlatform/1.8.0.6
16:49:30:326
HTTP response headers for jack.vxml:
   HTTP/1.0 503 Service Unavailable
   Proxy-Connection: close
   Expires: Thu, 20 Feb 2003 00:49:31 GMT
   Date: Thu, 20 Feb 2003 00:49:31 GMT
   Server: squid/2.5.STABLE1
   Content-Length: 1285
   X-Squid-Error: ERR_DNS_FAIL 0
   Content-Type: text/html
   X-Cache: MISS from proxy01.x.bevocal.com
   Mime-Version: 1.0

Fetch from a resource it *does* have access to
16:51:52:537
HTTP request headers for jack.vxml:
   Host: www.somewhere.com
   User-Agent: BeVocal/2.4 VoiceXML/2.0 BVPlatform/1.8.0.6

16:51:52:662
HTTP response headers for jack.vxml:
   HTTP/1.0 200 OK
   Proxy-Connection: close
   Accept-Ranges: bytes
   Date: Thu, 20 Feb 2003 00:47:55 GMT
   Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_jk/1.2.0 
mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b
   Content-Length: 14853
   ETag: "19f7e5-3a05-3e3b1965"
   Last-Modified: Sat, 01 Feb 2003 00:48:37 GMT
   Content-Type: text/plain
   X-Cache: MISS from proxy01.x.bevocal.com

Fetch the same resource again a minute or two later...
16:56:31:115
HTTP request headers for jack.vxml:
   Host: www.zenstarstudio.com
   User-Agent: BeVocal/2.4 VoiceXML/2.0 BVPlatform/1.8.0.6

16:56:31:115
HTTP response headers for jack.vxml:
   HTTP/1.0 200 OK
   Proxy-Connection: close
   Accept-Ranges: bytes
   Date: Thu, 20 Feb 2003 00:47:55 GMT
   Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_jk/1.2.0 
mod_perl/1.24_01 PHP/4.2.2 FrontPage/5.0.2 mod_ssl/2.8.5 OpenSSL/0.9.6b
   Content-Length: 14853
   ETag: "19f7e5-3a05-3e3b1965"
   Last-Modified: Sat, 01 Feb 2003 00:48:37 GMT
   Age: 517
   Content-Type: text/plain
   X-Cache: HIT from from proxy01.x.bevocal.com


	

	



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] nominate Michael Becke as a committer

[dion]

+1
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


"Armando Anton" <[EMAIL PROTECTED]> wrote on 20/02/2003 04:51:47 
AM:

> +1
> 
> -Original Message-
> From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
> Sent: miércoles, 19 de febrero de 2003 18:28
> To: Commons HttpClient Project
> Subject: [VOTE] nominate Michael Becke as a committer
> 
> 
> 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 ideas and criticism.
> 
> There are many excellent contributors to HttpClient, but at this time I 
> would like to nominate Michael Becke to be a committer to HttpClient.
> 
> Please Vote:
> +1   yes
> +/-0 obstain
> -1   no
> 
> 
> -
> 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]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] SSLProtocolSocketFactory

[Eric Johnson]

Great!

I also noticed that Sun's HttpsURLConnection class
allows you to specify a HostNameVerifier.  I'm not
really sure how this works but it might be worth
thinking about including in httpclient.

Eric

--- Michael Becke <[EMAIL PROTECTED]> wrote:
> Attached is a patch that adds an 
> SSLProtocolSocketFactory(SSLSocketFactory)
> constructor.  This is just a 
> convenience constructor so someone does not have to
> re-implement this 
> class to use a custom SSLSocketFactory.
> 
> Mike
> 
> >
-
> To unsubscribe, e-mail:
>
[EMAIL PROTECTED]
> For additional commands, e-mail:
[EMAIL PROTECTED]


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: What about optional components?

[Adrian Sutton]

Oleg et al,
I think this would be an excellent solution.  Perhaps it could start out as
a "useful tools and tips" page?  We could provide the code to detect proxy
settings in applets there as a start and am sure there's other stuff that
could be added as well?

Post 2.1 we could then expand this to provide support for development of
these add-ons etc similar to how ant does.

Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com


-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 20 February 2003 2:08 AM
To: Commons HttpClient Project
Subject: What about optional components?


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 (thinking about) collecting
contributions or optional packages (pretty much in the same manner Ant
is structured into core & optional packages) that are not officially an
integral part of HttpClient, nevertheless useful enough to be made
available to the public? Would it be worthwhile having a greater ecology
around HttpClient? Any thoughts?

Cheers

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Fix for bug 16458

[Oleg Kalnichevski]

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/msg00536.html

I was not aware that it might have fixed bug# 16458. Could you please
take the newest CVS snapshout for a spin and let us know if the problem
has indeed been eliminated?

Other patches would be highly welcome

Cheers

Oleg


On Wed, 2003-02-19 at 23:23, Sam Maloney wrote:
> Hi there,
> 
> As I am a new poster here, I will first describe myself and the situation. If 
> you wish to skip this, skip down to after the line '-'.
> 
> In a very large project I am a senior on, I use to be using HTTPClient v0.3-3 
> (www.innovation.ch/java/HTTPClient/).
> 
> At the time I chose it, it was the superior client. However, because of the 
> facts:
> 
> a) It does not work properly with sending the request as a stream without 
> knowing the content length until stream.close(). (It claimed to work okay 
> with this).
> 
> b) After looking at the code to try to fix the problem, not only did I give up 
> trying to fix the problem, but I also gave up on the product :)
> 
> So anyways, hearing 2.0alpha of HttpClient was out, and supported both SSL 
> (needed) and Streams (very good), I decided to try it out.
> 
> I want to point out that I encountered bug 13463 early on, and after reading 
> the bugzilla db, I tried the patch attached to the end of it. I would just 
> like to give my vote to include it into CVS, as it fixes the problem (bug 
> 13463) perfectly.
> 
> -
> 
> As for bug 16458, I have fixed it.
> 
> It was a rather simple bug, and can be reproduced by closing the server side 
> socket while the client is still waiting for a response. This will cause the 
> client to take 100% cpu, and it will do so for ever and ever.
> 
> The fix is as follows (I have tested extensively any fixes I will post):
> 
> Index: HttpConnection.java
> ===
> RCS file: 
> 
>/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
> retrieving revision 1.44
> diff -u -r1.44 HttpConnection.java
> --- HttpConnection.java   13 Feb 2003 21:31:53 -  1.44
> +++ HttpConnection.java   19 Feb 2003 21:27:26 -
> @@ -128,6 +128,10 @@
>  
>  StringBuffer buf = new StringBuffer();
>  int ch = inputStream.read();
> +if(ch == -1){
> +// End Of File!
> +return null; // Let caller know!
> +}
>  while (ch >= 0) {
>  if (ch == '\r') {
>  ch = inputStream.read();
> 
> I have another bugfix that I will post in my next message.
> 
> Thanks,
> Sam Maloney <[EMAIL PROTECTED]>
> 
> -
> 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]

[PATCH] Fix for bug 16458

[Sam Maloney]

Hi there,

As I am a new poster here, I will first describe myself and the situation. If 
you wish to skip this, skip down to after the line '-'.

In a very large project I am a senior on, I use to be using HTTPClient v0.3-3 
(www.innovation.ch/java/HTTPClient/).

At the time I chose it, it was the superior client. However, because of the 
facts:

a) It does not work properly with sending the request as a stream without 
knowing the content length until stream.close(). (It claimed to work okay 
with this).

b) After looking at the code to try to fix the problem, not only did I give up 
trying to fix the problem, but I also gave up on the product :)

So anyways, hearing 2.0alpha of HttpClient was out, and supported both SSL 
(needed) and Streams (very good), I decided to try it out.

I want to point out that I encountered bug 13463 early on, and after reading 
the bugzilla db, I tried the patch attached to the end of it. I would just 
like to give my vote to include it into CVS, as it fixes the problem (bug 
13463) perfectly.

-

As for bug 16458, I have fixed it.

It was a rather simple bug, and can be reproduced by closing the server side 
socket while the client is still waiting for a response. This will cause the 
client to take 100% cpu, and it will do so for ever and ever.

The fix is as follows (I have tested extensively any fixes I will post):

Index: HttpConnection.java
===
RCS file: 
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpConnection.java,v
retrieving revision 1.44
diff -u -r1.44 HttpConnection.java
--- HttpConnection.java 13 Feb 2003 21:31:53 -  1.44
+++ HttpConnection.java 19 Feb 2003 21:27:26 -
@@ -128,6 +128,10 @@
 
 StringBuffer buf = new StringBuffer();
 int ch = inputStream.read();
+if(ch == -1){
+// End Of File!
+return null; // Let caller know!
+}
 while (ch >= 0) {
 if (ch == '\r') {
 ch = inputStream.read();

I have another bugfix that I will post in my next message.

Thanks,
Sam Maloney <[EMAIL PROTECTED]>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Proxy-Connection: close header

[Adrian Sutton]

Ah really!  Excellent, I'd love to have a local test machine set up that
does it.  Currently I'm in the process of uploading a new build of our
entire product so that an external client can tell me whether or not the
problem is fully resolved.

I do a pretty good proxy impersonation with netcat but there are distinct
limits to that approach. :)

Do you have any idea how to make squid use that header?

Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com


-Original Message-
From: Laura Werner [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 20 February 2003 7:47 AM
To: Commons HttpClient Project
Subject: Re: Proxy-Connection: close header


Adrian Sutton wrote:

>Just run into a non-standards compliance problem with IIS proxies in
certain
>configurations.  At times instead of returning a "Connection: close"
header,
>it returns a "Proxy-connection: close" header.
>
For what it's worth, I've noticed that Squid sometimes uses a 
Proxy-Connection header as well.  So whatever patch you come up with 
will probably be useful for more than just IIS. 

Laura Werner
BeVocal



-
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]

RE: [VOTE] nominate Michael Becke as a committer

[Adrian Sutton]

A non-binding +1 from me then. :)

Adrian Sutton, Software Engineer
Ephox Corporation
www.ephox.com


-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 20 February 2003 4:32 AM
To: Commons HttpClient Project
Subject: Re: [VOTE] nominate Michael Becke as a committer


In general, I support anyone that wants to vote.  Due to the structure 
of Apache and Jakarta, only committer votes are binding so only these 
votes are reported to the PMC and recorded.

If we get to a point where the committers disagree with the community as 
a whole, then I want to know about it.

The best way to do that is for everyone that is interested to vote.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] nominate Michael Becke as a committer

[Oleg Kalnichevski]

+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 ideas and criticism.
> 
> There are many excellent contributors to HttpClient, but at this time I 
> would like to nominate Michael Becke to be a committer to HttpClient.
> 
> Please Vote:
> +1   yes
> +/-0 obstain
> -1   no
> 
> 
> -
> 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]

Re: Proxy-Connection: close header

[Laura Werner]

Adrian Sutton wrote:


Just run into a non-standards compliance problem with IIS proxies in certain
configurations.  At times instead of returning a "Connection: close" header,
it returns a "Proxy-connection: close" header.


For what it's worth, I've noticed that Squid sometimes uses a 
Proxy-Connection header as well.  So whatever patch you come up with 
will probably be useful for more than just IIS. 

Laura Werner
BeVocal



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] SSLProtocolSocketFactory

[Michael Becke]

Attached is a patch that adds an 
SSLProtocolSocketFactory(SSLSocketFactory) constructor.  This is just a 
convenience constructor so someone does not have to re-implement this 
class to use a custom SSLSocketFactory.

Mike

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

NOMINATE HttpClient committers

[Jeffrey Dever]

I would like to nominate the following committers from the Commons 
HttpClient project to the PMC.  They are all very active and have been 
for many months.  There are other committers that could be nominated, 
but the following are those whose primary association to Jakarta is 
through HttpClient:

Jeff Dever <[EMAIL PROTECTED]> (me)
Ortwin Glück <[EMAIL PROTECTED]>
Oleg Kalnichevski <[EMAIL PROTECTED]>

Jeff Dever
HttpClient release prime



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Changes to Jakarta

[Jeffrey Dever]

There are some changes coming down the pipe for the structure of 
Jakarta.  I have not been involved in these types of discussions untill 
now, and am still grappling with what is going on.  The most immeadiate 
issue is who is going to make up the PMC.  The idea seems to be that all 
committers are eiligible and desirable to be on the PMC.

I'm going to nominate the HttpClient specific committers (Odi, Oleg and 
myself) to make sure our voice is heard.  One ramification is that only 
PMC members will have binding votes for releases in the future.

Some of the discussion is here, but there is much more on general@jakarta:
http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]&msgNo=14439


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with SSL Certificate

[Michael Becke]

Yes, as Eric is saying you have to register your SSLSocketFactory with 
HttpClient.  To do this you have to register it with the Protocol class 
using something like:

  Protocol myHttpsProtocol = new Protocol("https", new 
MySSLProtocolSocketFactory(), 443);
  Protocol.registerProtocol("https", myHttpsProtocol);

Take a look at 
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory. For how 
to implement MySSLProtocolSocketFactory.

Now that I look at this we should probably add a constructor to 
SSLProtocolSocketFactory that accepts an instance of SSLSocketFactory. 
This would make things a little more convenient.

Mike

Eric Johnson wrote:
Hi,

I brought this up on the commons dev thread and forgot
to post the idea here.

You'll need to write your own implementation of the
SecureProtocolSocketFactory to replace the
SSLProtocolSocketFactory implementation.  Add a
socketFactory argument to the constructor of this
class and use the socket factory instead of the calls
to SSLSocketFactory.getDefault() used in
SSLProtocolSocketFactory.

I think this idea ought to replace
SSLProtocolSocketFactory FWIW.  I just hadn't had time
to send it in or type up the code for it yet.

Eric Johnson (not the one that regularly contributes,
but one that might like to in the near future.)

:)

--- Carlos_Cortés_del_Valle_de_la_Lastra
<[EMAIL PROTECTED]> wrote:


I have a problem using httpclient classes. I need
connect through https protocol with PostMethod. But,
when I execute the method, an Exception ocurred
because it doesn't find the certificate i've created
for this

public class RobotImpl{

   //Init server...
   public void iniciar() throws ExceptionGlobal{
   try{
   URL u = new
URL("https://localhost:8443/Jsp2.jsp";);
   org.apache.commons.httpclient.URI
uri=new org.apache.commons.httpclient.URI(u);
   HttpClient client = new
HttpClient();
   HostConfiguration hc = new
HostConfiguration();
   hc.setHost(uri);
   client.setHostConfiguration(hc);
   client.setTimeout(3);


   PostMethod post = new
PostMethod("https://localhost:8443/Jsp2.jsp";);

   int iResultCode =
client.executeMethod(post);
   }
   catch
...
}//end code



Exception Message

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: Couldn't
find trusted certificate
at


com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)


at



com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)


at



com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)


at



com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)


at



com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)


at



com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)...





I tried to create a trust manager that does not
validate certificate chains, but it doesn't works...
this is the code

TrustManager[] trustAllCerts = new TrustManager[]{
   new X509TrustManager() {
   public java.security.cert.X509Certificate[]
getAcceptedIssuers() {
   return null;
   }
   public void checkClientTrusted(
   java.security.cert.X509Certificate[]
certs, String authType) {
   }
   public void checkServerTrusted(
   java.security.cert.X509Certificate[]
certs, String authType) {
   }
   }
};
// Install the all-trusting trust manager
try {
   SSLContext sc = SSLContext.getInstance("SSL");
   sc.init(null, trustAllCerts, new
java.security.SecureRandom());
  


HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());


} catch (Exception e) {
}


thanks for advance,
Carlos




__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

-
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]

Re: Problem with SSL Certificate

[Eric Johnson]

Hi,

I brought this up on the commons dev thread and forgot
to post the idea here.

You'll need to write your own implementation of the
SecureProtocolSocketFactory to replace the
SSLProtocolSocketFactory implementation.  Add a
socketFactory argument to the constructor of this
class and use the socket factory instead of the calls
to SSLSocketFactory.getDefault() used in
SSLProtocolSocketFactory.

I think this idea ought to replace
SSLProtocolSocketFactory FWIW.  I just hadn't had time
to send it in or type up the code for it yet.

Eric Johnson (not the one that regularly contributes,
but one that might like to in the near future.)

:)

--- Carlos_Cortés_del_Valle_de_la_Lastra
<[EMAIL PROTECTED]> wrote:
> I have a problem using httpclient classes. I need
> connect through https protocol with PostMethod. But,
> when I execute the method, an Exception ocurred
> because it doesn't find the certificate i've created
> for this
> 
> public class RobotImpl{
> 
> //Init server...
> public void iniciar() throws ExceptionGlobal{
> try{
> URL u = new
> URL("https://localhost:8443/Jsp2.jsp";);
> org.apache.commons.httpclient.URI
> uri=new org.apache.commons.httpclient.URI(u);
> HttpClient client = new
> HttpClient();
> HostConfiguration hc = new
> HostConfiguration();
> hc.setHost(uri);
> client.setHostConfiguration(hc);
> client.setTimeout(3);
> 
> 
> PostMethod post = new
> PostMethod("https://localhost:8443/Jsp2.jsp";);
> 
> int iResultCode =
> client.executeMethod(post);
> }
> catch
> ...
> }//end code
> 
> 
> 
> Exception Message
> 
> javax.net.ssl.SSLHandshakeException:
> java.security.cert.CertificateException: Couldn't
> find trusted certificate
>  at
>
com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
>  at
>
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>  at
>
com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
>  at
>
com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
>  at
>
com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
>  at
>
com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)...
> 
> 
> 
> I tried to create a trust manager that does not
> validate certificate chains, but it doesn't works...
> this is the code
> 
> TrustManager[] trustAllCerts = new TrustManager[]{
> new X509TrustManager() {
> public java.security.cert.X509Certificate[]
> getAcceptedIssuers() {
> return null;
> }
> public void checkClientTrusted(
> java.security.cert.X509Certificate[]
> certs, String authType) {
> }
> public void checkServerTrusted(
> java.security.cert.X509Certificate[]
> certs, String authType) {
> }
> }
> };
> // Install the all-trusting trust manager
> try {
> SSLContext sc = SSLContext.getInstance("SSL");
> sc.init(null, trustAllCerts, new
> java.security.SecureRandom());
>
>
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
> } catch (Exception e) {
> }
> 
> 
> thanks for advance,
> Carlos


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] nominate Michael Becke as a committer

[Jeffrey Dever]

In general, I support anyone that wants to vote.  Due to the structure 
of Apache and Jakarta, only committer votes are binding so only these 
votes are reported to the PMC and recorded.

If we get to a point where the committers disagree with the community as 
a whole, then I want to know about it.

The best way to do that is for everyone that is interested to vote.


Ortwin Glück wrote:

Erm... maybe Jeff should of mentioned that

"Once a Contributor is nominated, all of the Committers for a 
subproject will vote." (see http://jakarta.apache.org/site/roles.html)

Contributors' votes do not count unfortunately. But of course it's 
nice to see what everybody thinks.

Armando Anton wrote:

+1




-
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]

RE: [VOTE] nominate Michael Becke as a committer

[Armando Anton]

uppps :)

just saying Michael is doing fantastic :)

-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]]
Sent: miércoles, 19 de febrero de 2003 19:06
To: Commons HttpClient Project
Subject: Re: [VOTE] nominate Michael Becke as a committer


Erm... maybe Jeff should of mentioned that

"Once a Contributor is nominated, all of the Committers for a subproject 
will vote." (see http://jakarta.apache.org/site/roles.html)

Contributors' votes do not count unfortunately. But of course it's nice 
to see what everybody thinks.

Armando Anton wrote:
> +1


-
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]

Re: [VOTE] nominate Michael Becke as a committer

[Ortwin Glück]

Erm... maybe Jeff should of mentioned that

"Once a Contributor is nominated, all of the Committers for a subproject 
will vote." (see http://jakarta.apache.org/site/roles.html)

Contributors' votes do not count unfortunately. But of course it's nice 
to see what everybody thinks.

Armando Anton wrote:
+1



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] nominate Michael Becke as a committer

[Armando Anton]

+1

-Original Message-
From: Jeffrey Dever [mailto:[EMAIL PROTECTED]]
Sent: miércoles, 19 de febrero de 2003 18:28
To: Commons HttpClient Project
Subject: [VOTE] nominate Michael Becke as a committer


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 ideas and criticism.

There are many excellent contributors to HttpClient, but at this time I 
would like to nominate Michael Becke to be a committer to HttpClient.

Please Vote:
+1   yes
+/-0 obstain
-1   no


-
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]

Re: [VOTE] nominate Michael Becke as a committer

[Jeffrey Dever]

+1

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 ideas and criticism.

There are many excellent contributors to HttpClient, but at this time 
I would like to nominate Michael Becke to be a committer to HttpClient.

Please Vote:
+1   yes
+/-0 obstain
-1   no


-
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]

Re: [VOTE] nominate Michael Becke as a committer

[Ortwin Glück]

+1

I do fully support Jeff's words!

Ortwin Glück

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 ideas and criticism.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problem with SSL Certificate

[Carlos Cortés del Valle de la Lastra]

I have a problem using httpclient classes. I need connect through https protocol with 
PostMethod. But, when I execute the method, an Exception ocurred because it doesn't 
find the certificate i've created for this

public class RobotImpl{

//Init server...
public void iniciar() throws ExceptionGlobal{
try{
URL u = new URL("https://localhost:8443/Jsp2.jsp";);
org.apache.commons.httpclient.URI uri=new 
org.apache.commons.httpclient.URI(u);
HttpClient client = new HttpClient();
HostConfiguration hc = new HostConfiguration();
hc.setHost(uri);
client.setHostConfiguration(hc);
client.setTimeout(3);


PostMethod post = new PostMethod("https://localhost:8443/Jsp2.jsp";);

int iResultCode = client.executeMethod(post);
}
catch
...
}//end code



Exception Message

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Couldn't 
find trusted certificate
 at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(DashoA6275)
 at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(DashoA6275)...



I tried to create a trust manager that does not validate certificate chains, but it 
doesn't works... this is the code

TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
}
};
// Install the all-trusting trust manager
try {
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (Exception e) {
}


thanks for advance,
Carlos

[VOTE] nominate Michael Becke as a committer

[Jeffrey Dever]

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 ideas and criticism.

There are many excellent contributors to HttpClient, but at this time I 
would like to nominate Michael Becke to be a committer to HttpClient.

Please Vote:
+1   yes
+/-0 obstain
-1   no


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What about optional components?

[Jeffrey Dever]

 - a Cache (mentioned a while ago on the list)


A possibility, but likely more re-usable as a seperate project (there is 
currently the beginnings of a cache in the sandbox, but appears idle)

 - Proxy-Detection


Another possibility


 - Some kind of "User-Agent" on top of HttpClient which:
- handles Framesets (return urls of subframes)
- possibly parses FORM-Tags
- eventually handles JavaScript-Code and
  return the complete page (with document.write()-statements
  executed).
- many more dreams here ...
 

This is definately outside the scope of httpclient.  Remember that 
HttpClient is HTTP (which is complex enough).  HTML parsing and handling 
would be a seperate project.

 I guess the generic User-Agent-part might become the next bigger
 project that leverages HttpClients functionality. Although it will
 need a lot of discussion to be generic & usefull enough for many
 people.
 

Cool idea.  Think through the functionality that is required, and divide 
into packages.
1) http connectivity
2) cache
3) html parsing
4) javascript parsing


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What about optional components?

[Ortwin Glück]

Max Voelkel wrote:

  - a Cache (mentioned a while ago on the list)
  - Proxy-Detection


okay


  - Some kind of "User-Agent" on top of HttpClient which:
 - handles Framesets (return urls of subframes)
 - possibly parses FORM-Tags
 - eventually handles JavaScript-Code and
   return the complete page (with document.write()-statements
   executed).
 - many more dreams here ...


This has *nothing* to do with HTTP (the focus of HttpClient) at all - 
that is only HTML. HTTP is much more than transporting HTML!

HTML Parsers are already available for Java. No need for us to build one 
into HttpClient. If anything then a HTTP Parses should go as a new 
project under Commons or even Jakarta.

Odi


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What about optional components?

[Jeffrey Dever]

Interesting.  It sounds like we are talking about a 2.2 (or 3.0 feature) 
but it is possible.  One conern I have is that HttpClient is a very 
large project as part of commons, and if we do increase its scope then 
we may also be considering moving to be a top level Jakarta project.

I would not suggest this now, but perhaps this might be in store for 3.0.

Jandlaf.


Michael Becke wrote:

Sounds like a fine idea Oleg.

I agree we should probably look to other jakarta project for how they 
handle this kind of thing.  As you said Ant does this and I believe 
Log4j does as well.

Mike

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 reached the point where we should start (thinking about) collecting
contributions or optional packages (pretty much in the same manner Ant
is structured into core & optional packages) that are not officially an
integral part of HttpClient, nevertheless useful enough to be made
available to the public? Would it be worthwhile having a greater ecology
around HttpClient? Any thoughts?

Cheers

Oleg

On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:

Could we provide the code below in some Utility function?
I guess this is convenient for people making Applets  - although 
Applets
are generally a bad idea :-)


Sadly, this code will not work on OS X or most non-sun JREs.  The 
location
of proxy information is very much platform, JVM and plugin 
dependant.  I'd
say it would be a bad idea to include this in HttpClient, but 
including it
as an initial starting point in the docs may be worth while.

I guess it depends what the scope of HttpClient is, but I would have 
thought
that the proxy configuration should be something that's passed into
HttpClient rather than something it tries to figure out.  A separate 
project
which detects proxy settings in applets on various platforms, has the
ability to parse the auto-configuration pages for proxies etc, but 
it really
is a big can of worms that I don't think HttpClient needs (particularly
coming up to a release).

Adrian Sutton.


-
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]



-
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]

Re: What about optional components?

[Max Voelkel]

Hi Oleg and all,

  I am using HttpClient for my diploma thesis and read this list for
  two months now. I guess, there is really the demand for more optional
  components around HttpClient, like:

  - a Cache (mentioned a while ago on the list)
  - Proxy-Detection
  - Some kind of "User-Agent" on top of HttpClient which:
 - handles Framesets (return urls of subframes)
 - possibly parses FORM-Tags
 - eventually handles JavaScript-Code and
   return the complete page (with document.write()-statements
   executed).
 - many more dreams here ...

  I guess the generic User-Agent-part might become the next bigger
  project that leverages HttpClients functionality. Although it will
  need a lot of discussion to be generic & usefull enough for many
  people.

Max


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What about optional components?

[Michael Becke]

Sounds like a fine idea Oleg.

I agree we should probably look to other jakarta project for how they 
handle this kind of thing.  As you said Ant does this and I believe 
Log4j does as well.

Mike

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 reached the point where we should start (thinking about) collecting
contributions or optional packages (pretty much in the same manner Ant
is structured into core & optional packages) that are not officially an
integral part of HttpClient, nevertheless useful enough to be made
available to the public? Would it be worthwhile having a greater ecology
around HttpClient? Any thoughts?

Cheers

Oleg

On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:

Could we provide the code below in some Utility function?
I guess this is convenient for people making Applets  - although Applets
are generally a bad idea :-)


Sadly, this code will not work on OS X or most non-sun JREs.  The location
of proxy information is very much platform, JVM and plugin dependant.  I'd
say it would be a bad idea to include this in HttpClient, but including it
as an initial starting point in the docs may be worth while.

I guess it depends what the scope of HttpClient is, but I would have thought
that the proxy configuration should be something that's passed into
HttpClient rather than something it tries to figure out.  A separate project
which detects proxy settings in applets on various platforms, has the
ability to parse the auto-configuration pages for proxies etc, but it really
is a big can of worms that I don't think HttpClient needs (particularly
coming up to a release).

Adrian Sutton.


-
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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

What about optional components?

[Oleg Kalnichevski]

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 (thinking about) collecting
contributions or optional packages (pretty much in the same manner Ant
is structured into core & optional packages) that are not officially an
integral part of HttpClient, nevertheless useful enough to be made
available to the public? Would it be worthwhile having a greater ecology
around HttpClient? Any thoughts?

Cheers

Oleg

On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
> > Could we provide the code below in some Utility function?
> > I guess this is convenient for people making Applets  - although Applets
> > are generally a bad idea :-)
> 
> Sadly, this code will not work on OS X or most non-sun JREs.  The location
> of proxy information is very much platform, JVM and plugin dependant.  I'd
> say it would be a bad idea to include this in HttpClient, but including it
> as an initial starting point in the docs may be worth while.
> 
> I guess it depends what the scope of HttpClient is, but I would have thought
> that the proxy configuration should be something that's passed into
> HttpClient rather than something it tries to figure out.  A separate project
> which detects proxy settings in applets on various platforms, has the
> ability to parse the auto-configuration pages for proxies etc, but it really
> is a big can of worms that I don't think HttpClient needs (particularly
> coming up to a release).
> 
> Adrian Sutton.
> 
> 
> -
> 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]

Re: proxy and howto's and some questions.

[Adrian Sutton]

> Could we provide the code below in some Utility function?
> I guess this is convenient for people making Applets  - although Applets
> are generally a bad idea :-)

Sadly, this code will not work on OS X or most non-sun JREs.  The location
of proxy information is very much platform, JVM and plugin dependant.  I'd
say it would be a bad idea to include this in HttpClient, but including it
as an initial starting point in the docs may be worth while.

I guess it depends what the scope of HttpClient is, but I would have thought
that the proxy configuration should be something that's passed into
HttpClient rather than something it tries to figure out.  A separate project
which detects proxy settings in applets on various platforms, has the
ability to parse the auto-configuration pages for proxies etc, but it really
is a big can of worms that I don't think HttpClient needs (particularly
coming up to a release).

Adrian Sutton.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: proxy and howto's and some questions.

[Nick Coleman]

Feel free to do with this code as you will.  If it was in a generic Apache
utility it would probably be better maintained in the future.

-Nick

-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, February 19, 2003 4:27 AM
To: Commons HttpClient Project
Subject: Re: proxy and howto's and some questions.


Could we provide the code below in some Utility function?
I guess this is convenient for people making Applets  - although Applets 
are generally a bad idea :-)

Nick, can we adopt this piece of code under the Apache License?

We should think about pac-proxy script parsing as well at some point.

Odi



Nick Coleman wrote:
> We detect the browser proxy settings as follows:
> 
> // Retrieve Proxy Server Settings from System if specified String 
> proxyList = System.getProperty("javaplugin.proxy.config.list");
> if (proxyList!=null && !"".equals(proxyList)){
>StringTokenizer tokenizer1 = new StringTokenizer(proxyList, ";,");
>if (tokenizer1.countTokens()>1){
>   while (tokenizer1.hasMoreTokens()){
>  String s = tokenizer1.nextToken();
>  if (s.toLowerCase().startsWith("http")){
> StringTokenizer tokenizer2 = new StringTokenizer(s, "=:");
> tokenizer2.nextToken();
> proxyHost = tokenizer2.nextToken();
> proxyPort = Integer.parseInt(tokenizer2.nextToken());
>  }
>   }
>}
>else {
>   StringTokenizer tokenizer = new StringTokenizer(proxyList, ":");
>   proxyHost = tokenizer.nextToken();
>   proxyPort = Integer.parseInt(tokenizer.nextToken());
>}
> }



-
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]

RE: Cactus and HttpClient encoding issue

[Vincent Massol]

Thanks Oleg. It does help a lot.

-Vincent

> -Original Message-
> From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]]
> Sent: 19 February 2003 14:22
> To: Commons HttpClient Project
> Subject: Re: Cactus and HttpClient encoding issue
> 
> 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 providing a content type header:
> 
> "Content-Type: text/plain; charset=UTF-8"
> 
> Per default ISO-8859-1 is used if either Content-Type header or
charset
> clause is missing.
> 
> HttpConstants class defines several constants that may prove of help
for
> you
> 
> HttpConstants#HTTP_ELEMENT_CHARSET - HTTP element encoding
> HttpConstants#DEFAULT_CONTENT_CHARSET - Default content encoding
> 
> I hope this helps
> 
> Cheers
> 
> Oleg
> 
> 
> On Wed, 2003-02-19 at 13:37, Vincent Massol wrote:
> > Hi,
> >
> > In Cactus land (which uses HttpClient), I have received a bug report
for
> > supporting different encodings
> > (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17077). Up until
now,
> > Cactus was using the default platform encoding for reading data from
> > streams. However, the bug reporter (Neal) who is developing on z/OS
told
> > me that all the HttpClient code is using a "hardcoded" encoding of
ASCII
> > (I guess 8859-1).
> >
> > I now need to modify Cactus so that Cactus plays ball with
HttpClient. I
> > have 2 questions:
> >
> > 1/ Is it possible in HttpClient for the user to choose which
encoding to
> > use?
> > 2/ Is there a HttpClient API I can query from Cactus to know which
> > encoding is being used by HttpClient?
> >
> > Thanks
> > -Vincent
> >
> >
> >
-
> > To unsubscribe, e-mail: commons-httpclient-dev-
> [EMAIL PROTECTED]
> > For additional commands, e-mail: commons-httpclient-dev-
> [EMAIL PROTECTED]
> >
> 
> 
> -
> To unsubscribe, e-mail: commons-httpclient-dev-
> [EMAIL PROTECTED]
> For additional commands, e-mail: commons-httpclient-dev-
> [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cactus and HttpClient encoding issue

[Oleg Kalnichevski]

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 providing a content type header: 

"Content-Type: text/plain; charset=UTF-8" 

Per default ISO-8859-1 is used if either Content-Type header or charset
clause is missing.

HttpConstants class defines several constants that may prove of help for
you 

HttpConstants#HTTP_ELEMENT_CHARSET - HTTP element encoding
HttpConstants#DEFAULT_CONTENT_CHARSET - Default content encoding

I hope this helps 

Cheers

Oleg


On Wed, 2003-02-19 at 13:37, Vincent Massol wrote:
> Hi,
> 
> In Cactus land (which uses HttpClient), I have received a bug report for
> supporting different encodings
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17077). Up until now,
> Cactus was using the default platform encoding for reading data from
> streams. However, the bug reporter (Neal) who is developing on z/OS told
> me that all the HttpClient code is using a "hardcoded" encoding of ASCII
> (I guess 8859-1).
> 
> I now need to modify Cactus so that Cactus plays ball with HttpClient. I
> have 2 questions:
> 
> 1/ Is it possible in HttpClient for the user to choose which encoding to
> use?
> 2/ Is there a HttpClient API I can query from Cactus to know which
> encoding is being used by HttpClient?
> 
> Thanks
> -Vincent
> 
> 
> -
> 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]

Cactus and HttpClient encoding issue

[Vincent Massol]

Hi,

In Cactus land (which uses HttpClient), I have received a bug report for
supporting different encodings
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17077). Up until now,
Cactus was using the default platform encoding for reading data from
streams. However, the bug reporter (Neal) who is developing on z/OS told
me that all the HttpClient code is using a "hardcoded" encoding of ASCII
(I guess 8859-1).

I now need to modify Cactus so that Cactus plays ball with HttpClient. I
have 2 questions:

1/ Is it possible in HttpClient for the user to choose which encoding to
use?
2/ Is there a HttpClient API I can query from Cactus to know which
encoding is being used by HttpClient?

Thanks
-Vincent


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: proxy and howto's and some questions.

[Ortwin Glück]

Could we provide the code below in some Utility function?
I guess this is convenient for people making Applets  - although Applets 
are generally a bad idea :-)

Nick, can we adopt this piece of code under the Apache License?

We should think about pac-proxy script parsing as well at some point.

Odi



Nick Coleman wrote:
We detect the browser proxy settings as follows:

// Retrieve Proxy Server Settings from System if specified
String proxyList = System.getProperty("javaplugin.proxy.config.list");
if (proxyList!=null && !"".equals(proxyList)){
   StringTokenizer tokenizer1 = new StringTokenizer(proxyList, ";,");
   if (tokenizer1.countTokens()>1){
  while (tokenizer1.hasMoreTokens()){
 String s = tokenizer1.nextToken();
 if (s.toLowerCase().startsWith("http")){
StringTokenizer tokenizer2 = new StringTokenizer(s, "=:");
tokenizer2.nextToken();
proxyHost = tokenizer2.nextToken();
proxyPort = Integer.parseInt(tokenizer2.nextToken());
 }
  }
   }
   else {
  StringTokenizer tokenizer = new StringTokenizer(proxyList, ":");
  proxyHost = tokenizer.nextToken();
  proxyPort = Integer.parseInt(tokenizer.nextToken());
   }
}




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17166] - HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17166

HttpClient does not compile 'out of the box' in IBM's VisualAge IDE

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.0 Beta 1



--- Additional Comments From [EMAIL PROTECTED]  2003-02-19 09:18 ---
IBM's compiler is known to be a bit picky about the syntax sometimes (which
personally I find okay). Strange though, that Eclipse does not have problems.
Easy to fix and important to make the sources compatible to common compilers. So
scheduling this for beta.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17158] - Realm from authentication challenge unavailable

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17158

Realm from authentication challenge unavailable

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |2.0 Beta 1



--- Additional Comments From [EMAIL PROTECTED]  2003-02-19 09:15 ---
Important feature and easy to implement. So scheduling this for the beta.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]