Nabble - HttpComponents-Dev

[HttpClient] HttpClient 4.0.1 / 4.1-alpha1 preview packages

2009-11-26T13:47:06Z

Folks

Please do try to find a few minutes to review the pre-release packages
and release notes. If no one complains until Sunday I will assume
everything is all right and will proceed with building the official
release packages.

HttpClient 4.0.1
================
Release notes:
http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt

Preview packages:
http://people.apache.org/~olegk/httpclient-4.0.1/

HttpClient 4.1 ALPHA1
================
Release notes:
http://people.apache.org/~olegk/httpclient-4.1-alpha1/RELEASE_NOTES.txt

Preview packages:
http://people.apache.org/~olegk/httpclient-4.1-alpha1/

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Closed: (HTTPCLIENT-884) Charset omitted from UrlEncodedFormEntity Content-Type header

2009-11-26T08:40:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jared Jacobs closed HTTPCLIENT-884.
-----------------------------------

Fix looks good. I noticed that this issue was omitted from the release notes. Only HTTPCLIENT-885 was mentioned. I believe this issue is more serious than HTTPCLIENT-885 because the library uses the faulty code to send all url-form-encoded entities, whereas the faulty code in HTTPCLIENT-885 is not used internally by the library at all.

> Charset omitted from UrlEncodedFormEntity Content-Type header
> -------------------------------------------------------------
>
> Key: HTTPCLIENT-884
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-884
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: all
> Reporter: Jared Jacobs
> Priority: Minor
> Fix For: 4.0.1, 4.1 Alpha1
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> UrlEncodedFormEntity sets the Content-Type header to:
> "application/x-www-form-urlencoded"
> It should set the header to:
> "application/x-www-form-urlencoded; charset=" + charset
> As a result, content can be misinterpreted by the recipient (e.g. if the entity content includes multibyte Unicode characters encoded with the "UTF-8" charset).
> For a correct example of specifying the charset in the Content-Type header, see StringEntity.java.
> Here's the fix:
> public UrlEncodedFormEntity (
> final List <? extends NameValuePair> parameters,
> final String encoding) throws UnsupportedEncodingException {
> super(URLEncodedUtils.format(parameters, encoding), encoding);
> - setContentType(URLEncodedUtils.CONTENT_TYPE);
> + setContentType(URLEncodedUtils.CONTENT_TYPE + HTTP.CHARSET_PARAM +
> + (encoding != null ? encoding : HTTP.DEFAULT_CONTENT_CHARSET));
> }
> public UrlEncodedFormEntity (
> final List <? extends NameValuePair> parameters) throws UnsupportedEncodingException {
> - super(URLEncodedUtils.format(parameters, HTTP.DEFAULT_CONTENT_CHARSET),
> - HTTP.DEFAULT_CONTENT_CHARSET);
> - setContentType(URLEncodedUtils.CONTENT_TYPE);
> + this(parameters, HTTP.DEFAULT_CONTENT_CHARSET);
> }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Closed: (HTTPCLIENT-885) URLEncodedUtils fails to parse form-url-encoded entities that specify a charset

2009-11-26T08:26:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jared Jacobs closed HTTPCLIENT-885.
-----------------------------------

Fix and associated test case look good to me. Thanks.

> URLEncodedUtils fails to parse form-url-encoded entities that specify a charset
> -------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-885
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-885
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: all
> Reporter: Jared Jacobs
> Priority: Minor
> Fix For: 4.0.1, 4.1 Alpha1
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> If a form-url-encoded HTTP entity specifies a charset in its Content-Type header, then URLEncodedUtils.parse(HttpEntity) fails to parse it.
> An entity with content type "application/x-www-form-urlencoded; charset=UTF-8" should be detected as form-url-encoded and parsed as such, honoring the specified character set. Currently the code requires an exact, case-insensitive match with "application/x-www-form-urlencoded" for an entity to be detected as form-url-encoded.
> It appears that the author of URLEncodedUtils.parse(HttpEntity) tried to take character sets into account, but expected to find them in the Content-Encoding header instead of as a parameter in the Content-Length header. The HTTP 1.1 spec makes it clear that the Content-Encoding header is for specifying transformations like gzip compression or the identity transformation -- not for specifying the entity's character set.
> Here are some helpful links.
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11
> This is related to: https://issues.apache.org/jira/browse/HTTPCLIENT-884

[jira] Resolved: (HTTPCLIENT-865) HttpClient OSGi Export-Package doesn't specify version

2009-11-25T12:42:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-865.
------------------------------------------

Resolution: Fixed

Fixed in SVN trunk

Oleg

> HttpClient OSGi Export-Package doesn't specify version
> ------------------------------------------------------
>
> Key: HTTPCLIENT-865
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-865
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Beta 2
> Reporter: Richard Wallace
> Fix For: 4.1 Alpha1
>
>
> The "Export-Package" manifest entry doesn't specify the version of the package being exported. This means that packages importing it can't specify a version to import.

[jira] Resolved: (HTTPCORE-210) Provide HttpMethodbase.getResponseMimeType

2009-11-25T12:08:39Z

[ https://issues.apache.org/jira/browse/HTTPCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCORE-210.
----------------------------------------

Resolution: Fixed

Implemented in SVN trunk

Oleg

> Provide HttpMethodbase.getResponseMimeType
> ------------------------------------------
>
> Key: HTTPCORE-210
> URL: https://issues.apache.org/jira/browse/HTTPCORE-210
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.1-alpha1
> Reporter: Kenny MacLeod
> Priority: Minor
> Fix For: 4.1-beta1
>
>
> HttpMethodBase already provides a getResponseCharSet() method which decodes the "Content-Type" header, but discards the mime-type part of the header, via getContentCharSet(). Most of the work is already done here for exposing the mime-type part to the public API.

Re: [jira] Resolved: (HTTPCLIENT-873) CoreConnectionPNames/HttpConnectionParams doesn't have a corresponding Bean class

2009-11-25T01:49:31Z

Oleg Kalnichevski (JIRA) wrote:
> until 5.0

What a word!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Moved: (HTTPCORE-210) Provide HttpMethodbase.getResponseMimeType

2009-11-25T01:34:29Z

[ https://issues.apache.org/jira/browse/HTTPCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski moved HTTPCLIENT-802 to HTTPCORE-210:
-------------------------------------------------------

Component/s: (was: HttpClient)
HttpCore
Fix Version/s: (was: 4.1 Alpha1)
4.1-beta1
Affects Version/s: (was: 3.1 Final)
4.1-alpha1
Key: HTTPCORE-210 (was: HTTPCLIENT-802)
Project: HttpComponents HttpCore (was: HttpComponents HttpClient)

[jira] Resolved: (HTTPCLIENT-873) CoreConnectionPNames/HttpConnectionParams doesn't have a corresponding Bean class

2009-11-25T01:32:02Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-873.
------------------------------------------

Resolution: Won't Fix
Fix Version/s: (was: 4.1 Alpha1)

> CoreConnectionPNames/HttpConnectionParams are missing the bean class.

Actually there is HttpConnectionParamBean already. It must have been overlooked. Inconsistent class names are unfortunate but something we will have to live with until 5.0

Oleg

> CoreConnectionPNames/HttpConnectionParams doesn't have a corresponding Bean class
> ---------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-873
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-873
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Gerald Turner
> Priority: Minor
>
> The HttpParams framework seems to follow a policy of having:
> • an interface to declare the parameter string constant (e.g. ConnManagerPNames.TIMEOUT), also AllPNames implements this interface.
> • a class containing static accessors for the parameter (e.g. ConnManagerParams.get/setTimeout)
> • a bean class with accessors (sometimes setters only) for the parameter (e.g. ConnManagerParamBean.setTImeout)
> CoreConnectionPNames/HttpConnectionParams are missing the bean class.
> Furthermore the class name HttpConnectionParams doesn't quite follow the style (should be named CoreConnectionParams), but ClientPNames/HttpClientParams also has this oddity.

[jira] Commented: (HTTPCLIENT-892) Links in Section "Example Code" are broken

2009-11-25T01:10:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782344#action_12782344 ]

Martin Dürrmeier commented on HTTPCLIENT-892:
---------------------------------------------

Ah ok, got it

> Links in Section "Example Code" are broken
> ------------------------------------------
>
> Key: HTTPCLIENT-892
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-892
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 4.0 Final
> Environment: Firefox 3.5.5, IE 7
> Reporter: Martin Dürrmeier
> Fix For: 4.0.1, 4.1 Alpha1
>
>
> Steps to Reproduce: Go to http://hc.apache.org/user-docs.html
> Click of one of the Links in the Section "Example Code"

[jira] Commented: (HTTPCLIENT-892) Links in Section "Example Code" are broken

2009-11-25T01:04:53Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782343#action_12782343 ]

Oleg Kalnichevski commented on HTTPCLIENT-892:
----------------------------------------------

The links have been fixed in the source repository but the project site has not been redeployed yet. There is likely to be a new release sometime next week and I will update the web site along with the new release.

Oleg

[jira] Commented: (HTTPCLIENT-892) Links in Section "Example Code" are broken

2009-11-24T23:44:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782332#action_12782332 ]

Martin Dürrmeier commented on HTTPCLIENT-892:
---------------------------------------------

Oleg does this mean the posted link should already work? (which it isn't, I refreshed my cache)
I changed the Urls a little and found the Examples, could you check again?

HttpCore:
is http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/module-main/src/examples/org/apache/http/examples/
works with: http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore/src/examples/org/apache/http/examples/

HttpCore NIO:
is http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/module-nio/src/examples/org/apache/http/examples/nio/
works with: http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-nio/src/examples/org/apache/http/examples/nio/

HttpClient:
is http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-client/src/examples/org/apache/http/examples/client/
works with: http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/examples/org/apache/http/examples/client/

HttpMime:
is http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/module-httpmime/src/examples/org/apache/http/examples/entity/mime/
works with: http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpmime/src/examples/org/apache/http/examples/entity/mime/

[jira] Commented: (HTTPCLIENT-862) Extend the client's redirect handling interface to allow control of the content of the redirect

2009-11-24T18:16:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782281#action_12782281 ]

Ben Perkins commented on HTTPCLIENT-862:
----------------------------------------

Thanks Oleg. Yes, I will take a look.

> Extend the client's redirect handling interface to allow control of the content of the redirect
> -----------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-862
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-862
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Beta 2
> Reporter: Ben Perkins
> Fix For: 4.1 Alpha1
>
>
> The existing RedirectHandler interface provides the ability influence which situations cause redirects, but gives you no control over the content of the redirect itself. For example, if you want the client follow the redirect of a POST request with a POST request to the new location, you can't do it. DefaultRequestDirector decides what method will be used on the redirect request and as of the most recent patch, it's always either a HEAD or a GET.
> One option for resolving this might be extending the RedirectHandler interface to be a factory for creating the redirect request object. The the DefaultRequestDirector could then be changed to ask the RedirectHandler to create the appropriate request for the situation.
> Thanks,
> Ben

[jira] Resolved: (HTTPCLIENT-892) Links in Section "Example Code" are broken

2009-11-24T13:03:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-892.
------------------------------------------

Resolution: Fixed

Fixed in SVN

Oleg

[jira] Resolved: (HTTPCLIENT-889) Should USE_EXPECT_CONTINUE be false by default?

2009-11-24T12:53:40Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-889.
------------------------------------------

Resolution: Fixed

Fixed in SVN trunk.

Oleg

> Should USE_EXPECT_CONTINUE be false by default?
> -----------------------------------------------
>
> Key: HTTPCLIENT-889
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-889
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Ren Waldura
> Priority: Minor
> Fix For: 4.1 Alpha1
>
>
> It seems the point of USE_EXPECT_CONTINUE is to improve performance when posting large data.
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html says:
> << The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body. >>
> There's nothing wrong with HttpClient performing well by default, however, every other HTTP client library I've used does not behave like this (PHP curl, Perl LWP). The default is always to do one request, including the body. Maybe dumb, but simple.
> It seems to me HttpClient's default behavior should the simplest, most compatible with all HTTP-speaking services out there. "100 Continue" is somewhat advanced, and may not be correctly implemented by all services. (That's of course how I found out about it -- my server doesn't implement it.)
> If USE_EXPECT_CONTINUE is used only for performance reasons, it seems like it would be simpler (and therefore maybe more "correct") to have it "off" by default. And only enable it when needed, when there is a good reason to.
> Just my thoughts. And a wish. Thanks!

[jira] Resolved: (HTTPCLIENT-862) Extend the client's redirect handling interface to allow control of the content of the redirect

2009-11-24T12:47:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-862.
------------------------------------------

Resolution: Fixed

Fixed in SVN trunk.

Ben, could you please review / test the new API?

Oleg

[jira] Resolved: (HTTPCLIENT-894) To decrease the number of connections for connection manager dynamically.

2009-11-24T02:04:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-894.
------------------------------------------

Resolution: Invalid
Fix Version/s: (was: 3.1.1)

> 1) Is there any way or alternative to decrease the connections dynamically without shutting down connection manager?

The connection manager will gradually decrease the number of connections in the pool as they expire. It will not drop open connections proactively. The only way to alter this behavior is building a custom connection manager .

> 2) What will happen to those threads using my client if i shutdown my manager in bertween request processing?

The connection manager will be rendered unusable. However, one can close all active connections in the pool by calling #closeIdleConnections(0)

Please in the future DO NOT USE JIRA to ask questions. That is what mailing lists are for.

Oleg

> To decrease the number of connections for connection manager dynamically.
> -------------------------------------------------------------------------
>
> Key: HTTPCLIENT-894
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-894
> Project: HttpComponents HttpClient
> Issue Type: Question
> Components: HttpClient
> Affects Versions: 3.1 Final
> Environment: Windows
> Reporter: Alok Chaudhary
> Priority: Minor
>
> Hello,
> I have a quick query regarding MultiThreadedHttpConnectionManager. At the application startup, i fetched no of connections value from my cache. Based on the connection value, i initialized MultiThreadedHttpConnectionManager.
> MultiThreadedHttpConnectionManager mgr = new MultiThreadedHttpConnectionManager() ;
> mgr.getParams().setDefaultMaxConnectionsPerHost(10);
> mgr.getParams().setMaxTotalConnections(10);
> HttpClient client = new HttpClient(mgr) ;
> Now if i dynamically increase the no of connections say "12" in my cache then my netstas shows me 12 connections. I dont have any issue in this.
> But when i dynamically decrease the number of connections say "8", connection manager does not reflect the "8" connections. Netstat still shows "12" connections in established state.
> I have 20 threads those are using my HttpClient, so i dont want to shut down my connection manager.
> My questions are:
> 1) Is there any way or alternative to decrease the connections dynamically without shutting down connection manager?
> 2) What will happen to those threads using my client if i shutdown my manager in bertween request processing?
> Any help will be appreciated.

[jira] Updated: (HTTPCLIENT-892) Links in Section "Example Code" are broken

2009-11-24T01:50:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski updated HTTPCLIENT-892:
-----------------------------------------

Fix Version/s: 4.1 Alpha1
4.0.1

[jira] Resolved: (HTTPCLIENT-893) SSL connection is giving exception- SSL Bad record Mac

2009-11-24T01:50:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-893.
------------------------------------------

Resolution: Invalid

This problem has NOTHING to do with HttpClient. DO NOT use JIRA for asking questions. That's what mailing lists are for.

Oleg

> SSL connection is giving exception- SSL Bad record Mac
> ------------------------------------------------------
>
> Key: HTTPCLIENT-893
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-893
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 3.1 Final
> Reporter: Pankaj
>
> I am using Http commons to talk to my server.
> I am facing an issue where after every few https calls I see this error:
> javax.net.ssl.SSLException: bad record MAC
> at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591
> )
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1549
> )
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java
> :850)
> at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.
> java:746)
> at
> com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
> at
> java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at
> java.io.BufferedInputStream.read(BufferedInputStream.java:237)
> at
> org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
> at
> org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
> at
> org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
> a:1115)
> Sometime there is no error for 100 of calls and sometimes it errors in
> 6-7 calls.
> Any ideas what might be wrong or if there is some existing bug in Http commons or even Sun?
> Thanks,
> Pankaj Arora

[jira] Created: (HTTPCLIENT-894) To decrease the number of connections for connection manager dynamically.

2009-11-23T11:33:47Z

To decrease the number of connections for connection manager dynamically.
-------------------------------------------------------------------------

Key: HTTPCLIENT-894
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-894
Project: HttpComponents HttpClient
Issue Type: Question
Components: HttpClient
Affects Versions: 3.1 Final
Environment: Windows
Reporter: Alok Chaudhary
Priority: Minor
Fix For: 3.1.1

Hello,

I have a quick query regarding MultiThreadedHttpConnectionManager. At the application startup, i fetched no of connections value from my cache. Based on the connection value, i initialized MultiThreadedHttpConnectionManager.

MultiThreadedHttpConnectionManager mgr = new MultiThreadedHttpConnectionManager() ;
mgr.getParams().setDefaultMaxConnectionsPerHost(10);
mgr.getParams().setMaxTotalConnections(10);
HttpClient client = new HttpClient(mgr) ;

Now if i dynamically increase the no of connections say "12" in my cache then my netstas shows me 12 connections. I dont have any issue in this.
But when i dynamically decrease the number of connections say "8", connection manager does not reflect the "8" connections. Netstat still shows "12" connections in established state.

I have 20 threads those are using my HttpClient, so i dont want to shut down my connection manager.

My questions are:
1) Is there any way or alternative to decrease the connections dynamically without shutting down connection manager?

2) What will happen to those threads using my client if i shutdown my manager in bertween request processing?

Any help will be appreciated.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Updated: (HTTPCLIENT-893) SSL connection is giving exception- SSL Bad record Mac

2009-11-23T10:21:40Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pankaj updated HTTPCLIENT-893:
------------------------------

Summary: SSL connection is giving exception- SSL Bad record Mac (was: SSL connection is giving exception some times)

[jira] Created: (HTTPCLIENT-893) SSL connection is giving exception some times

2009-11-23T10:21:40Z

SSL connection is giving exception some times
---------------------------------------------

Key: HTTPCLIENT-893
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-893
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Affects Versions: 3.1 Final
Reporter: Pankaj

I am using Http commons to talk to my server.
I am facing an issue where after every few https calls I see this error:

javax.net.ssl.SSLException: bad record MAC

at
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591
)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1549
)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java
:850)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.
java:746)

at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)

at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at
java.io.BufferedInputStream.read(BufferedInputStream.java:237)

at
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)

at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)

at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
a:1115)

Sometime there is no error for 100 of calls and sometimes it errors in
6-7 calls.
Any ideas what might be wrong or if there is some existing bug in Http commons or even Sun?

Thanks,
Pankaj Arora

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Created: (HTTPCLIENT-892) Links in Section "Example Code" are broken

2009-11-23T00:26:39Z

Links in Section "Example Code" are broken
------------------------------------------

Key: HTTPCLIENT-892
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-892
Project: HttpComponents HttpClient
Issue Type: Bug
Components: Documentation
Affects Versions: 4.0 Final
Environment: Firefox 3.5.5, IE 7
Reporter: Martin Dürrmeier

Steps to Reproduce: Go to http://hc.apache.org/user-docs.html
Click of one of the Links in the Section "Example Code"

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

SSL Bad record Mac

2009-11-20T18:36:59Z

HI,
I am using Http commons 3.0.1 to talk to my server.
I am facing an issue where after every few https calls I see this error:

javax.net.ssl.SSLException: bad record MAC

at
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591
)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1549
)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java
:850)

at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.
java:746)

at
com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)

at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at
java.io.BufferedInputStream.read(BufferedInputStream.java:237)

at
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)

at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)

at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
a:1115)

Sometime there is no error for 100 of calls and sometimes it errors in
6-7 calls.
Any ideas what might be wrong or if there is some existing bug in Http
commons or even Sun?

Thanks,
Pankaj Arora

-----Original Message-----
From: Kiss Gergely [mailto:kiss.gergely@...]
Sent: Thursday, November 19, 2009 1:53 AM
To: HttpComponents Project
Subject: Re: NegotiateAuth for HttpClient 4.x

Oleg,

Because we required a stable version of HttpComponents, the code was
based
on 4.0.
Doh... I should have looked at the JIRA first :)

As for digging in the current docs and trunk... sorry, but I'm already
promising my free time (and future free time) to everybody, so maybe
some
other day.

Best regards
Gergely Kiss

> Gergely,
>
> Support for SPNEGO/Kerberos authentication scheme has been recently
> added to the SVN trunk (See HTTPCLIENT-523 in JIRA for details). Did
you

> base your code on 4.0 release or the latest dev snapshot? If not, it
> would be great if you could incorporate the latest changes into your
> code line and submit your enhancements as a patch against SVN trunk.
>
> There is also a fairly extensive documentation of how current SPNEGO
> support works in the HttpClient tutorial but you will have to generate
> that tutorial manually from the source code.
>
> Please also consider subscribing the the list so I would not have mod
> your messages in manually.
>
> Cheers
>
> Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: NegotiateAuth for HttpClient 4.x

2009-11-19T01:53:25Z

Oleg,

Because we required a stable version of HttpComponents, the code was based
on 4.0.
Doh... I should have looked at the JIRA first :)

As for digging in the current docs and trunk... sorry, but I'm already
promising my free time (and future free time) to everybody, so maybe some
other day.

Best regards
Gergely Kiss

> Gergely,
>
> Support for SPNEGO/Kerberos authentication scheme has been recently
> added to the SVN trunk (See HTTPCLIENT-523 in JIRA for details). Did you
> base your code on 4.0 release or the latest dev snapshot? If not, it
> would be great if you could incorporate the latest changes into your
> code line and submit your enhancements as a patch against SVN trunk.
>
> There is also a fairly extensive documentation of how current SPNEGO
> support works in the HttpClient tutorial but you will have to generate
> that tutorial manually from the source code.
>
> Please also consider subscribing the the list so I would not have mod
> your messages in manually.
>
> Cheers
>
> Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (HTTPCLIENT-872) Add preemptive authentication

2009-11-18T21:55:08Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779837#action_12779837 ]

Asankha C. Perera commented on HTTPCLIENT-872:
----------------------------------------------

This is excellent.. the new example looks very elegant and is much easier to use

> Add preemptive authentication
> -----------------------------
>
> Key: HTTPCLIENT-872
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-872
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpAuth
> Affects Versions: 4.0 Final
> Reporter: Gerald Turner
> Fix For: 4.1 Alpha1
>
> Attachments: PreemptiveAuth.patch
>
>
> Wishlist request for preemptive authentication to be included in the API, like HttpClient 3.x had. There is an example ClientPreemptiveBasicAuthentication.java that uses HttpRequestInterceptor which I had adapted to my application and it works fine.

[jira] Resolved: (HTTPCLIENT-872) Add preemptive authentication

2009-11-18T13:16:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kalnichevski resolved HTTPCLIENT-872.
------------------------------------------

Resolution: Fixed

* HttpClient can now persist authentication data between request executions as long as they share the same execution context.
* It has also become much easier to make HttpClient authenticate preemptively by pre-populating authentication data cache

Compare old code (4.0):
http://svn.apache.org/repos/asf/httpcomponents/httpclient/branches/4.0.x/httpclient/src/examples/org/apache/http/examples/client/ClientPreemptiveBasicAuthentication.java
http://svn.apache.org/repos/asf/httpcomponents/httpclient/branches/4.0.x/httpclient/src/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java

with new one (4.1):
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/examples/org/apache/http/examples/client/ClientPreemptiveBasicAuthentication.java
http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java

Please review / test / give feedback

Re: NegotiateAuth for HttpClient 4.x

2009-11-18T03:59:48Z

On Wed, 2009-11-18 at 10:03 +0100, Kiss Gergely wrote:

> Dear HttpComponent Developers,
>
> We're using HttpComponents 4.x in out project for some time now, and last
> week I spent a lot of time figuring out how Exchange works with WebDAV and
> Kerberos authentication.
> In the meantime, I have implemented the NegotiateScheme class for 4.x -
> based on Mikael Wikstrom's previous work for HttpClient 3.x - which I'd like
> to contribute back to the community.
>
> Notes:
> - with 4.x it's a bit harder to add a new authentication scheme, but is
> possible with DefaultHttpClient.setTargetAuthenticationHandler() - so the
> new authPreferences should look like { "negotiate", "ntlm", "digest",
> "basic" }
> - unfortunately the current (4.0) implementation does not fall back to Basic
> or Digest if Negotiate or NTLM authentication failed, so you have to decide
> which one to use before executing the request
> - The execute() call is required to run in a JAAS context (with
> Subject.doAs(...))
> - Kerberos authentication requires a service name to work (the first part of
> the SPN), and this was a constant value ("HTTP") in the previous version -
> but the target service may already have another SPN (so registering HTTP
> would be unnecessary). For this reason, I introduced the
> parameter NegotiateSchemeFactory.SERVICE_PREFIX, which is read from the
> HttpParams specified to the client.
> - Credential delegation was tested and works very nicely
>
> Best regards
> Gergely Kiss
>

Gergely,

Support for SPNEGO/Kerberos authentication scheme has been recently
added to the SVN trunk (See HTTPCLIENT-523 in JIRA for details). Did you
base your code on 4.0 release or the latest dev snapshot? If not, it
would be great if you could incorporate the latest changes into your
code line and submit your enhancements as a patch against SVN trunk.

There is also a fairly extensive documentation of how current SPNEGO
support works in the HttpClient tutorial but you will have to generate
that tutorial manually from the source code.

Please also consider subscribing the the list so I would not have mod
your messages in manually.

Cheers

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

NegotiateAuth for HttpClient 4.x

2009-11-18T01:03:54Z

Dear HttpComponent Developers,

We're using HttpComponents 4.x in out project for some time now, and last
week I spent a lot of time figuring out how Exchange works with WebDAV and
Kerberos authentication.
In the meantime, I have implemented the NegotiateScheme class for 4.x -
based on Mikael Wikstrom's previous work for HttpClient 3.x - which I'd like
to contribute back to the community.

Notes:
- with 4.x it's a bit harder to add a new authentication scheme, but is
possible with DefaultHttpClient.setTargetAuthenticationHandler() - so the
new authPreferences should look like { "negotiate", "ntlm", "digest",
"basic" }
- unfortunately the current (4.0) implementation does not fall back to Basic
or Digest if Negotiate or NTLM authentication failed, so you have to decide
which one to use before executing the request
- The execute() call is required to run in a JAAS context (with
Subject.doAs(...))
- Kerberos authentication requires a service name to work (the first part of
the SPN), and this was a constant value ("HTTP") in the previous version -
but the target service may already have another SPN (so registering HTTP
would be unnecessary). For this reason, I introduced the
parameter NegotiateSchemeFactory.SERVICE_PREFIX, which is read from the
HttpParams specified to the client.
- Credential delegation was tested and works very nicely

Best regards
Gergely Kiss

===========================================
NegotiateSchemeFactory.java:
===========================================
package org.apache.http.impl.auth;

import org.apache.http.auth.AuthScheme;
import org.apache.http.auth.AuthSchemeFactory;
import org.apache.http.params.HttpParams;

/**
* Negotiate scheme factory for HttpClient 4.x.
*
* @author <a href="mailto:kiss.gergely@...">Gergely Kiss</a>
*/
public class NegotiateSchemeFactory implements AuthSchemeFactory {

/**
* Service prefix for the Kerberos SPN.
*
* This is HTTP by default, but some services may already have
another SPN.
*/
public static final String SERVICE_PREFIX = "KerberosServiceName";

public AuthScheme newInstance(HttpParams params) {
NegotiateScheme scheme = new NegotiateScheme();

// Setting the service prefix, if specified
Object param = params.getParameter(SERVICE_PREFIX);

if (param != null) {
scheme.setServicePrefix(String.valueOf(param));
}

return scheme;
}
}

===========================================
NegotiateScheme.java:
===========================================
package org.apache.http.impl.auth;

import org.apache.commons.codec.binary.Base64;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import org.apache.http.Header;
import org.apache.http.HttpRequest;
import org.apache.http.auth.AUTH;
import org.apache.http.auth.AuthScheme;
import org.apache.http.auth.AuthenticationException;
import org.apache.http.auth.Credentials;
import org.apache.http.auth.InvalidCredentialsException;
import org.apache.http.auth.MalformedChallengeException;
import org.apache.http.message.BasicHeader;

import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;

/**
* Authentication scheme implementing the Negotiate protocol with JAAS for
HTTPClient 4.x.
*
* @author <a href="mailto:mikael.wikstrom@...">Mikael Wikstrom</a>
* @author <a href="mailto:kiss.gergely@...">Gergely Kiss</a>
*/
public class NegotiateScheme implements AuthScheme {

/** Log object for this class. */
private static final Log log = LogFactory.getLog(NegotiateScheme.class);

private static final int UNINITIATED = 0;
private static final int INITIATED = 1;
private static final int NEGOTIATING = 3;
private static final int ESTABLISHED = 4;
private static final int FAILED = Integer.MAX_VALUE;

private GSSContext context = null;

/** Authentication process state */
private int state;

/** base64 decoded challenge * */
byte[] token = new byte[0];

/**
* Service prefix for the Kerberos SPN.
*
* This is usually HTTP, but another service name can also be
used.
*/
private String servicePrefix = "HTTP";

/**
* Default constructor for the Negotiate authentication scheme.
*
* @param subject
*
* @since 3.0
*/
public NegotiateScheme() {
super();
state = UNINITIATED;
}

/**
* Init GSSContext for negotiation.
*
* @param host servername only (e.g: radar.it.su.se)
*/
protected void init(String host) throws Exception {
log.debug("init " + host);

/* Kerberos v5 GSS-API mechanism defined in RFC 1964. */
Oid krb5Oid = new Oid("1.2.840.113554.1.2.2");
GSSManager manager = GSSManager.getInstance();
GSSName serverName = manager.createName(servicePrefix + "/" + host,
null);
context = manager.createContext(serverName, krb5Oid, null,
GSSContext.DEFAULT_LIFETIME);
context.requestCredDeleg(true);
context.requestMutualAuth(true);

state = INITIATED;
}

/**
* Processes the Negotiate challenge.
*
* @param challenge the challenge string
*
* @since 4.0
*/
public void processChallenge(Header header) throws
MalformedChallengeException {
String challenge = header.getValue();
log.debug("enter processChallenge(challenge=\"" + challenge +
"\")");

if (challenge.startsWith("Negotiate")) {

if (!isComplete()) {
state = NEGOTIATING;
}

if (challenge.startsWith("Negotiate ")) {
token = new
Base64().decode(challenge.substring(10).getBytes());
} else {
token = new byte[0];
}
}
}

/**
* Tests if the Negotiate authentication process has been completed.
*
* @return <tt>true</tt> if authorization has been processed,
<tt>false</tt> otherwise.
*
* @since 3.0
*/
public boolean isComplete() {
log.debug("enter isComplete()");

return (this.state == ESTABLISHED) || (this.state == FAILED);
}

/**
* Returns textual designation of the Negotiate authentication scheme.
*
* @return <code>Negotiate</code>
*/
public String getSchemeName() {
return "Negotiate";
}

/**
* The concept of an authentication realm is not supported by the
Negotiate authentication scheme. Always returns
* <code>null</code>.
*
* @return <code>null</code>
*/
public String getRealm() {
return null;
}

/**
* Returns the authentication parameter with the given name, if
available.
*
* There are no valid parameters for Negotiate authentication so this
method always returns <tt>null</tt>.
*
* @param name The name of the parameter to be returned
*
* @return the parameter with the given name
*/
public String getParameter(String name) {
log.debug("enter getParameter(" + name + ")");

if (name == null) {
throw new IllegalArgumentException("Parameter name may not be
null");
}

return null;
}

/**
* Returns <tt>true</tt>. Negotiate authentication scheme is connection
based.
*
* @return <tt>true</tt>.
*
* @since 3.0
*/
public boolean isConnectionBased() {
log.info("enter isConnectionBased()");

return true;
}

/**
* Produces Negotiate authorization string based on token created by
processChallenge.
*
* @param credentials Never used be the Negotiate scheme but must be
provided to satisfy common-httpclient API.
* Credentials from JAAS will be used insted.
* @param method The method being authenticated
*
* @return an Negotiate authorization string
*
* @throws AuthenticationException if authorization string cannot be
generated due to an authentication failure
*
* @since 4.0
*/
public Header authenticate(Credentials credentials, HttpRequest request)
throws AuthenticationException {
log.debug("enter NegotiateScheme.authenticate(Credentials,
HttpMethod)");

if (state == UNINITIATED) {
throw new IllegalStateException(
"Negotiation authentication process has not been
initiated");
}

try {

if (context == null) {
Header host = request.getFirstHeader("Host");

if (host != null) {
log.info("host: " + host);
init(host.getValue());
} else {
throw new AuthenticationException(
"Failed to get host name from header parameters");
}
}
} catch (AuthenticationException e) {
throw e;
} catch (Exception e) {
log.error(e.getMessage());
log.debug("Failure trace", e);
state = FAILED;
throw new AuthenticationException(e.getMessage());
}

try {

// HTTP 1.1 issue:
// Mutual auth will never complete do to 200 insted of 401 in
// return from server. "state" will never reach ESTABLISHED
// but it works anyway
token = context.initSecContext(token, 0, token.length);
log.info("got token, sending " + token.length + " to server");
} catch (GSSException e) {
log.error(e.getMessage());
log.debug("Failure trace", e);
state = FAILED;

if ((e.getMajor() == GSSException.DEFECTIVE_CREDENTIAL) ||
(e.getMajor() == GSSException.CREDENTIALS_EXPIRED)) {
throw new InvalidCredentialsException(e.getMessage(), e);
}

if (e.getMajor() == GSSException.NO_CRED) {
throw new InvalidCredentialsException(e.getMessage(), e);
}

if ((e.getMajor() == GSSException.DEFECTIVE_TOKEN) ||
(e.getMajor() == GSSException.DUPLICATE_TOKEN) ||
(e.getMajor() == GSSException.OLD_TOKEN)) {
throw new InvalidCredentialsException(e.getMessage(), e);
}

// other error
throw new AuthenticationException(e.getMessage());
}

return new BasicHeader(AUTH.WWW_AUTH_RESP,
"Negotiate " + new String(new Base64().encode(token)));
}

public void setServicePrefix(String servicePrefix) {
this.servicePrefix = servicePrefix;
}
}

[jira] Commented: (HTTPCLIENT-891) java.net.SocketException: Unconnected sockets not implemented thrown

2009-11-17T03:52:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778833#action_12778833 ]

shyam sundar g commented on HTTPCLIENT-891:
-------------------------------------------

Since this activity was in the process of fixing the socket connection failure i raised this query in this report.
OK i will raise in it other forums to seek support.

> java.net.SocketException: Unconnected sockets not implemented thrown
> --------------------------------------------------------------------
>
> Key: HTTPCLIENT-891
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-891
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: Application Server : Websphere application server 6.1.0.23
> Java : JDK 1.5.0.16
> Reporter: shyam sundar g
> Fix For: 4.0 Final
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Iam using HTTPClient 4.0 to connect a remote server and transfer file using HTTPS.
> When i tried to connect i get the exception "java.net.SocketException: Unconnected sockets not implemented".
> Please look at the stack trace
> java.net.SocketException: Unconnected sockets not implemented
> at java.lang.Throwable.<init>(Throwable.java:196)
> at java.lang.Exception.<init>(Exception.java:41)
> at java.io.IOException.<init>(IOException.java:40)
> at java.net.SocketException.<init>(SocketException.java:29)
> at javax.net.SocketFactory.createSocket(SocketFactory.java:2)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(Unknown Source)
> at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(Unknown Source)
> at org.apache.commons.httpclient.HttpConnection.open(Unknown Source)
> at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Unknown Source)
> at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(Unknown Source)
> at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
> at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
> at co.com.personalsoft.ftpseguro.utilidades.TransmisionHTTP.ejecutarTransmisionHTTP(TransmisionHTTP.java:107)
> at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmisionAuto(TransmisionFTPNew.java:483)
> at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmision(TransmisionFTPNew.java:1016)
> at co.com.personalsoft.ftpautomatico.ConexionThread.run(ConexionThread.java:58)
> at java.lang.Thread.run(Thread.java:595)
> The same error is found while using HTTP Client 3.1.
> Kindly help to solve this problem as the production deployment is delayed because of this error.

[jira] Commented: (HTTPCLIENT-891) java.net.SocketException: Unconnected sockets not implemented thrown

2009-11-17T01:24:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778786#action_12778786 ]

Ortwin Glück commented on HTTPCLIENT-891:
-----------------------------------------

Shyam, your last comment has nothing to do with the original bug report. Please don't hijack the topic and use the mailing lists.

[jira] Closed: (HTTPCLIENT-890) CLONE -Allow configuration of SO_LINGER (client socket close ReSet)

2009-11-16T17:01:43Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

thinker0 closed HTTPCLIENT-890.
-------------------------------

thanks. ^^;

> CLONE -Allow configuration of SO_LINGER (client socket close ReSet)
> -------------------------------------------------------------------
>
> Key: HTTPCLIENT-890
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-890
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Environment: Operating System: All
> Platform: All
> Reporter: thinker0
> Priority: Minor
>
> There is currently no way to configure the SO_LINGER option on a socket.
> Please change the HttpClient class to allow the configuration of the SO_LINGER
> option on a socket, similar to the way the SO_TIMEOUT can be configured.
> Suggested extension to the interface of the HttpClient class:
> - Add method setSoLinger() to set the current setting for SO_LINGER. The method
> could accept one argument. A negative value could indicate that the SO_LINGER
> should be disabled.
> - Add method getSoLinger() that returns the current setting for SO_LINGER. A
> negative value would indicate that the SO_LINGER option is disabled.
> See:
> http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setSoLinger(boolean,%20int)

[jira] Commented: (HTTPCLIENT-891) java.net.SocketException: Unconnected sockets not implemented thrown

2009-11-16T15:17:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778638#action_12778638 ]

shyam sundar g commented on HTTPCLIENT-891:
-------------------------------------------

Hi,I used HTTPPost method to connect to the server and it was working.
So we decided to migrate to HTTPClient 4.0 now.

I have a doubt here.How to mention the target path in the destination server
where the file uploaded should be saved.

In HTTPClient 3.1 the target path can be mentioned in MultiPartPost constructor method but in HTTPCLient 4 this class is removed.

Can i use MultiPartEntity object to mention the target path

Thankls for the support.

Thanks
Shyam

[REPORT] HttpComponents PMC - November 2009

2009-11-16T14:14:59Z

Status report for the Apache HttpComponents project - 11/2009
-------------------------------------------------------------

-- Status --

The project in general is floating along very smoothly; there are no
issues requiring the attention of the board.

-- Releases --

We have had one release since the last report:

13 September 2009 - HttpComponents HttpCore 4.1 Alpha 1

-- Community --

There were no changes in the composition of the committership since
the last report.

-- Development --

Development has slowed down a tiny bit after having reached two major
milestones (HttpCore 4.0 & HttpClient 4.0) recently.

Nevertheless, the first steps towards HttpCore 4.1 have been taken and
development activity is starting to pick up again.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (HTTPCLIENT-891) java.net.SocketException: Unconnected sockets not implemented thrown

2009-11-16T08:21:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778383#action_12778383 ]

Ortwin Glück commented on HTTPCLIENT-891:
-----------------------------------------

As you can see from the stack, the exception is from the JDK implementation. You must refer to the documentation of your vendor's JSSE implementation. We have no magic glass ball that could tell us those details.

[jira] Commented: (HTTPCLIENT-891) java.net.SocketException: Unconnected sockets not implemented thrown

2009-11-16T07:53:39Z

[ https://issues.apache.org/jira/browse/HTTPCLIENT-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778379#action_12778379 ]

shyam sundar g commented on HTTPCLIENT-891:
-------------------------------------------

hi,
Thanks for your response.

I reused the StrictSSLProtocolSocketFactory class and tried to connect to the server.The following exception
is thrown.
java.net.SocketException
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at java.io.IOException.<init>(IOException.java:40)
at java.net.SocketException.<init>(SocketException.java:29)
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:5)
at co.com.personalsoft.ftpseguro.utilidades.StrictSSLProtocolSocketFactory.createSocket(StrictSSLProtocolSocketFactory.java:181)
at co.com.personalsoft.ftpseguro.utilidades.StrictSSLProtocolSocketFactory.createSocket(StrictSSLProtocolSocketFactory.java:291)
at org.apache.commons.httpclient.HttpConnection.open(Unknown Source)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Unknown Source)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(Unknown Source)
at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
at org.apache.commons.httpclient.HttpClient.executeMethod(Unknown Source)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionHTTP.ejecutarTransmisionHTTP(TransmisionHTTP.java:145)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmisionAuto(TransmisionFTPNew.java:483)
at co.com.personalsoft.ftpseguro.utilidades.TransmisionFTPNew.ejecutarTransmision(TransmisionFTPNew.java:1016)
at co.com.personalsoft.ftpautomatico.ConexionThread.run(ConexionThread.java:58)
at java.lang.Thread.run(Thread.java:595)

I tried the configuration test program given in the link http://hc.apache.org/httpclient-3.x/sslguide.html

The line given below throwed exception.When i analysed this problem it is the createSocket method
throwing the exception NULL(returned by ex.getMessage() method).

Socket socket = SSLSocketFactory.getDefault().
createSocket(TARGET_HTTPS_SERVER, TARGET_HTTPS_PORT);

So the problem occurs when i try creating a socket to the destination server.

Please let me know where the problem could be.