Re: SOCKS Proxies

[Roland Weber]

Hi Sam,

SOCKS is a socket level protocol that is supposed to be transparent
for the application using the sockets. So you best take a look at
org.apache.commons.httpclient.protocol.ProtocolSocketFactory.
By implementing your own ProtocolSocketFactory, you are free to
return a plain socket or one that uses SOCKS.

cheers,
  Roland





Sam Berlin <[EMAIL PROTECTED]>
14.04.2004 19:04
Please respond to "Commons HttpClient Project"
 
To: [EMAIL PROTECTED]
cc: 
Subject:SOCKS Proxies


Hi All,

The website states the SOCKS proxies are supported by the setting the 
native java properties that convert Sockets to using SOCKS internally. 
Unfortunately, this solution is not possible for us, as we need to be 
able to create Sockets sometimes with and sometimes without SOCKS.

How would one go about implementing SOCKS as an additional proxying 
method (on the 2.0 code)?  Some rough pointers to the general classes 
that require changes would be useful.

Thanks much,
  Sam


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

[PATCH] SSL guide amendments (patch against 2.0 branch)

[Oleg Kalnichevski]

Folks,

Daniel C. Amadei has kindly contributed a paragraph on recently
discovered problem with bogus error messages caused by a bug in older
versions of Sun JSSE

I have also long promised to write a few words regarding the known
problems with IBM JSSE

Please let me know what you think. I would also like to kindly ask
someone of our resident native English speakers to proof-read the
writing

Cheers,

Oleg
PS: Daniel, I changed your original text somewhat. Please let me know if
you agree with the changes

Index: sslguide.xml
===
RCS file: /home/cvspublic/jakarta-commons/httpclient/xdocs/sslguide.xml,v
retrieving revision 1.2.2.1
diff -u -r1.2.2.1 sslguide.xml
--- sslguide.xml	21 Aug 2003 16:07:31 -	1.2.2.1
+++ sslguide.xml	14 Apr 2004 20:47:48 -
@@ -240,6 +240,45 @@
 
 
 
+
+
+ Socket timeout not correctly reported when using oder versions of JSSE 
+ (prior to Java 1.4)
+
+
+ There is a bug in older versions of Sun JSSE that causes timed out read operation to report end of 
+ stream condition instead of throwing java.io.InterruptedIOException as expected. As a result if read 
+ operation on a secure (SSL) connection times out (SO_TIMEOUT is set to a positive value) HttpClient 
+ mistakingly assumes that the connection was dropped and throws a recoverable HTTP exception: Error in
+ parsing the status line from the response: unable to find line starting with "HTTP" instead of 
+ "java.io.InterruptedIOException: Read timed out" as expected. If you get this message when working with
+ an older version of JDK and JSSE, it can be caused by the timeout waiting for data and not by a problem 
+ with the connection. 
+
+
+ Solution: One possible solution is to increase the timeout value as the server is 
+ taking too long to start sending the response. Alternatively you may choose to upgrade to Java 1.4 or 
+ above which does not exhibit this problem.
+
+
+ The problem has been discovered and reported by Daniel C. Amadei.
+
+
+
+
+
+ HttpClient does not work with IBM JSSE shipped with IBM Websphere Application Platform
+
+
+ There is a bug in several releases of IBM JSSE that causes HttpClient to fail while detecting the size 
+ of the socket send buffer (java.net.Socket.getSendBufferSize method throws java.net.SocketException: 
+ "Socket closed" exception).
+
+
+ Solution: Make sure that you have all the latest fix packs applied. IBM Websphere 
+ Application Server versions 4.0.6, 5.0.2.2, 5.1 have been reported to not exhibit the problem.
+
+
   
  
 

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

RE: BasicAuthentication with "Maximum redirects (100) exceeded" erro r

[Oleg Kalnichevski]

Lili,
Unauthorized access _should_ not be causing "Maximum redirects (100)
exceeded", unless there's a bug either on the server or client side.
Could you please post the complete wirelog (with sensitive data
obfuscated), so we could try to determine what may be causing the
problem?

Cheers,

Oleg


On Tue, 2004-04-13 at 23:37, Lili Liu wrote:
> Hi, Michael:
> I turned the log and found the following msg:
> 
> HTTP 401.4 - Unauthorized: Authorization denied by filter
> 
> I am using IIS5.1 and have 5 pre-installed filters on XP.
> 
> Is it really filter issue because I can pass Basic Authentication with
> java.net.HttpURLConnection code as follows?
> 
> import java.util.List;
> import java.net.URL;
> import java.net.MalformedURLException;
> import java.net.HttpURLConnection;
> import java.io.IOException;
> import sun.misc.BASE64Encoder;
> public class BasicAuthenticationExample1 {
> 
>   private static BASE64Encoder encoder = new BASE64Encoder();
> /**
>  * Constructor for BasicAuthenticatonExample.
>  */
> public BasicAuthenticationExample1() {
> }
> 
> public static void main(String[] args) throws Exception {
> 
> 
>URL url = null;
> try
> {
> url = new URL("http://10.8.9.22/index.html";);
> 
> }
> catch (MalformedURLException mue)
> {
> System.out.println("url not exist");
> }
> 
> // create a httpURLConnection to the url specified above
> // catch an IOException if a connection cannot be established
> HttpURLConnection connection = null;
> try
> {
> connection = (HttpURLConnection) url.openConnection();
> 
> }
> catch (IOException io)
> {
> System.out.println("no connection is established!");
> }
> 
> String authorization = encoder.encode(new String("username" + ":" +
> "password").getBytes());
> connection.setRequestProperty("Authorization", "Basic " +
> authorization);
> 
>   intresponseCode = connection.getResponseCode();
>   System.out.println(responseCode);
> }
> }
> 
> lili
> Thanks
> 
> -Original Message-
> From: Michael Becke [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 12, 2004 7:51 PM
> To: Commons HttpClient Project
> Subject: Re: BasicAuthentication with "Maximum redirects (100) exceeded"
> erro r
> 
> 
> Hi Lili,
> 
> It sounds like you've gotten into an recursive redirection loop.  
> Please post the wire log 
>  for a 
> couple of the redirections, and we should be able to diagnose the 
> problem.  Feel free to obfuscate any sensitive information in the logs.
> 
> Mike
> 
> On Apr 12, 2004, at 7:30 PM, Lili Liu wrote:
> 
> > Not sure whether this is the right group to ask questions.
> >
> > I am implementing BasicAuthenticationExample.java (distributed with
> > httpclient src) with IIS server on local host.
> > But I keep get the error msg:
> >
> > SEVERE: Narrowly avoided an infinite loop in execute
> > Exception in thread "main"
> > org.apache.commons.httpclient.HttpRecoverableExceptio
> > n: Maximum redirects (100) exceeded
> >
> > Any information is highly appreciated.
> > Thanks.
> > lili
> >
> > -
> > 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]

SOCKS Proxies

[Sam Berlin]

Hi All,

The website states the SOCKS proxies are supported by the setting the 
native java properties that convert Sockets to using SOCKS internally.  
Unfortunately, this solution is not possible for us, as we need to be 
able to create Sockets sometimes with and sometimes without SOCKS.

How would one go about implementing SOCKS as an additional proxying 
method (on the 2.0 code)?  Some rough pointers to the general classes 
that require changes would be useful.

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

DO NOT REPLY [Bug 28354] - unable to find line starting with "HTTP" message when timeout occurs

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28354

unable to find line starting with "HTTP" message when timeout occurs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-14 17:04 ---
I am glad the issue is resolved. I am looking forward to receiving your
contribution. You may post it to the HttpClient developers' mailing list if you
like, and I'll see that it gets incorporated into HttpClient SSL guide.

Oleg

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

DO NOT REPLY [Bug 28354] - unable to find line starting with "HTTP" message when timeout occurs

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28354

unable to find line starting with "HTTP" message when timeout occurs





--- Additional Comments From [EMAIL PROTECTED]  2004-04-14 16:48 ---
Hi Oleg!

That's it. With JDK 1.4.2 and the bundled JSSE I 
get "java.net.SocketTimeoutException: Read timed out".

Feel free to mark the bug invalid. I'll send you the contribution to be added 
via email.

Again, thanks a lot for your help.
Daniel C. Amadei

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

FW: [NOTICE] HttpClient is requesting to move from commons to Jakarta sub-project

[Kalnichevski, Oleg]

The message attached below was sent to general at jakarta.apache.org. Apparently 
there's something brewing. You may know our fate soon.

Oleg

-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 18:29
To: Jakarta General List
Subject: [NOTICE] HttpClient is requesting to move from commons to
Jakarta sub-project


All,

The HttpClient project has voted to ask to become a Jakarta
sub-project.  The PMC is voting on expanding Jakarta, and I personally
apologize to the community for accidentally holding the vote on the
private PMC list.  In order to keep confusion to to a minimum, we'll
keep it there and do better next time.

If anyone has any comments, speak now or forever hold it... :)

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
 


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


***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

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

RE: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level

[Kalnichevski, Oleg]

***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***
Adrian,
The message to [EMAIL PROTECTED] may not have gone through, as this is a restricted 
list (PMC members only). I believe we should try sending the proposal to [EMAIL 
PROTECTED] It appears the voting on HiveMind promotion, for instance, was held on that 
mailing list

Oleg

-Original Message-
From: Adrian Sutton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 2:56
To: [EMAIL PROTECTED]
Cc: Commons HttpClient Project
Subject: Fwd: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta
Level



Hi all,
Recently the Commons HttpClient project voted on a proposal to move
HttpClient out of Jakarta Commons to become a full Jakarta subproject.
The result of the vote is below.  It's our understanding that the
Jakarta PMC now needs to vote on the proposal as well.

Please advise us of any step in this process we're missing.

Regards,

Adrian Sutton.


Begin forwarded message:

> From: Adrian Sutton <[EMAIL PROTECTED]>
> Date: 29 March 2004 8:47:16 PM
> To: Commons HttpClient Project
> <[EMAIL PROTECTED]>
> Subject: [VOTE][PROPOSAL][RESULT] Promote HttpClient to Jakarta Level
> Reply-To: "Commons HttpClient Project"
> <[EMAIL PROTECTED]>
>
> The vote has passed.  We will put forth the proposal below to the
> Jakarta
> PMC to move HttpClient to a Jakarta level project.  The vote details
> are
> below:
>
> +1 votes -
> Adrian Sutton [EMAIL PROTECTED]
> Oleg Kalnichevski [EMAIL PROTECTED]
> Michael Becke [EMAIL PROTECTED]
> dIon Gillard [EMAIL PROTECTED]
>
> +0 votes -
> Ortwin Glück [EMAIL PROTECTED]
>
> Vote thread -
> http://nagoya.apache.org/eyebrowse/BrowseList?listName=commons-
> httpclient-de
> [EMAIL PROTECTED]&by=thread&fromh1919
>
>
> (0) RATIONALE
> HTTP is the main protocol used today on the internet.  Although the JDK
> includes basic support for building HTTP-aware client applications, it
> doesn't provide the flexibility or ease of use needed for many
> projects.
>
> The current package in Jakarta-Commons is a widely used implementation
> with
> a strong community behind it.  The size of it's community and it's
> project
> has significantly outgrown the commons project and a move to a Jakarta
> level
> project would provide better support for that community and for the on
> going
> development of HttpClient.
>
> (1) SCOPE
> The project shall create and maintain a Java library implementing the
> client
> side of the HTTP 1.0 and 1.1 protocol, as defined in RFC 1945, RFC
> 2616 and
> RFC 2617.
>
> HttpClient also supports the following RFCs.
>
> * RFC 2109 for HTTP state management mechanism (Cookies) - an upgrade
> to RFC
> 2965 is planned for a future version of HttpClient
>
> * RFC 2396 Uniform Resoruce Identifiers (URI): Generic Syntax
>
> * RFC 1867 Form-based File Upload in HTML
>
> The package should:
>
> * Have an API which should be as simple to use as possible
> * Be as easy to extend as possible
> * Provide unconditional support for HTTP/1.1
>
> The package is quite different from the HTTP client provided as part
> of the
> JDK (java.net.HttpURLConnection), as it focuses on the HTTP methods
> being
> sent (instead of making that transparent to the user), and generally
> allows
> more interaction with the lower level connection.  The JDK client is
> also
> not very intuitive to use.
>
> The package is used by a wide range of projects both within the ASF
> and from
> third parties.  These include:
>
> * Jakarta Slide
> * Jakarta Commons Latka
> * Nortel Networks
> * HtmlUnit
> * Jakarta Cactus
> * JSR 147
> * NOSE Applied Intelligence ag
> * MindIQ's Design-a-Course
> * ContactOffice
> * Newknow
> * de4d2c
> * Furies
> * Term Highlighting for Verity Ultraseek search results
> * Mule - Universal Message Objects
> * many more.
>
> (1.5) Interaction With Other Packages
>
> HttpClient relies on:
>
> * Java Development Kit (Version 1.2 or later; 1.3 or later recommended)
> * Jakarta commons-logging (Version 1.0 or later)
> * Jakarta commons-codec (Version 1.2 or later)
>
> (2) INITIAL SOURCE OF THE PACKAGE
>
> The initial codebase exists as a sub-project of Jakarta-Commons, in the
> httpclient subdirectory of the jakarta-commons cvs tree.
>
> The proposed package name for the new sub-project is
> org.apache.htt