[ https://issues.apache.org/jira/browse/HTTPCLIENT-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787818#action_12787818
]
Glyn Davies commented on HTTPCLIENT-875:
----------------------------------------
I'm looking at MultihomePlainSocketFactory which creates a new client socket object under
exception situations.
This new socket is returned, and replaces the initial socket that was created.
This would be fine if the update() replaced the existing socket straight away, but this fails
because the initial socket is not open.
> DefaultClientConnectionOperator doesn't update socket after call to connectSocket(...)
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-875
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-875
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Beta 2, 4.0 Final
> Reporter: Connell Gauld
> Fix For: 4.1 Alpha1
>
> Attachments: HTTPCLIENT-875-2.patch, HTTPCLIENT-875.diff
>
>
> In the DefaultClientConnectionOperator function openConnection(...) it calls SocketFactory.connectSocket(...).
The documentation for connectSocket(...) says that it returns:
> "the connected socket. The returned object may be different from
> the sock argument if this factory supports a layered protocol. "
> A quick peek at the source showed:
> In org.apache.http.impl.conn.DefaultClientConnectionOperator:
> 117 final SocketFactory sf = schm.getSocketFactory();
> 118
> 119 Socket sock = sf.createSocket();
> 120 conn.opening(sock, target);
> 121
> 122 try {
> 123 sock = sf.connectSocket(sock, target.getHostName(),
> 124 schm.resolvePort(target.getPort()),
> 125 local, 0, params);
> 126 } catch (ConnectException ex) {
> 127 throw new HttpHostConnectException(target, ex);
> 128 }
> 129 prepareSocket(sock, context, params);
> 130 conn.openCompleted(sf.isSecure(sock), params);
> So DefaultClientConnectionOperator never updates conn with the new version of sock that
may have been returned from connectSocket(...).
> adding:
> 130 conn.openCompleted(sf.isSecure(sock), params);
> +++ 131 conn.update(sock, target, sf.isSecure(sock), params);
> appears to fix the issue.
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787787#action_12787787
]
Oleg Kalnichevski commented on HTTPCLIENT-875:
----------------------------------------------
This is actually the expected behaviour of the method, see javadocs. Why it is a problem?
http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/OperatedClientConnection.html#update%28java.net.Socket,%20org.apache.http.HttpHost,%20boolean,%20org.apache.http.params.HttpParams%29
Oleg
> DefaultClientConnectionOperator doesn't update socket after call to connectSocket(...)
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-875
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-875
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Beta 2, 4.0 Final
> Reporter: Connell Gauld
> Fix For: 4.1 Alpha1
>
> Attachments: HTTPCLIENT-875-2.patch, HTTPCLIENT-875.diff
>
>
> In the DefaultClientConnectionOperator function openConnection(...) it calls SocketFactory.connectSocket(...).
The documentation for connectSocket(...) says that it returns:
> "the connected socket. The returned object may be different from
> the sock argument if this factory supports a layered protocol. "
> A quick peek at the source showed:
> In org.apache.http.impl.conn.DefaultClientConnectionOperator:
> 117 final SocketFactory sf = schm.getSocketFactory();
> 118
> 119 Socket sock = sf.createSocket();
> 120 conn.opening(sock, target);
> 121
> 122 try {
> 123 sock = sf.connectSocket(sock, target.getHostName(),
> 124 schm.resolvePort(target.getPort()),
> 125 local, 0, params);
> 126 } catch (ConnectException ex) {
> 127 throw new HttpHostConnectException(target, ex);
> 128 }
> 129 prepareSocket(sock, context, params);
> 130 conn.openCompleted(sf.isSecure(sock), params);
> So DefaultClientConnectionOperator never updates conn with the new version of sock that
may have been returned from connectSocket(...).
> adding:
> 130 conn.openCompleted(sf.isSecure(sock), params);
> +++ 131 conn.update(sock, target, sf.isSecure(sock), params);
> appears to fix the issue.
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-897.
------------------------------------------
Resolution: Won't Fix
HttpClient 3.x code line is effectively end of life. Please consider upgrading to HttpClient
4.0
Oleg
> java.lang.IllegalStateException: unsupported protocol: "<host name>" when using
ConnectMethod
> ---------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-897
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-897
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Environment: commons-httpclient-3.1.jar
> Reporter: Barry Silis
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> The method org.apache.commons.httpclient.ConnectMethod.getURI() omits the protocol from
the returned URI, causing an exception *java.lang.IllegalStateException* when trying to use
the class ConnectMethod.
> I believe it can be solved by not overriding org.apache.commons.httpclient.HttpMethodBase.getURI()
in the ConnectMethod class.
> The exception:
> Exception in thread "main" java.lang.IllegalStateException: unsupported protocol: 'www.google.com'
> at org.apache.commons.httpclient.protocol.Protocol.lazyRegisterProtocol(Protocol.java:149)
> at org.apache.commons.httpclient.protocol.Protocol.getProtocol(Protocol.java:117)
> at org.apache.commons.httpclient.HostConfiguration.setHost(HostConfiguration.java:253)
> at org.apache.commons.httpclient.HostConfiguration.setHost(HostConfiguration.java:315)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:388)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> at epicon.sbr.client.TestHttpGet.connectToProxy(TestHttpGet.java:293)
> at epicon.sbr.client.TestHttpGet.main(TestHttpGet.java:41)
> Cheers,
> Barry.
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787749#action_12787749
]
Glyn Davies commented on HTTPCLIENT-875:
----------------------------------------
This doesn't fix all cases as the call to conn.update() checks that the previous socket is
still open, by calling assertOpen()
If the original socket is screwed up (likely given the use case) this throws an 'IllegalStateEXception:
Connection is not open'
> DefaultClientConnectionOperator doesn't update socket after call to connectSocket(...)
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-875
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-875
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Beta 2, 4.0 Final
> Reporter: Connell Gauld
> Fix For: 4.1 Alpha1
>
> Attachments: HTTPCLIENT-875-2.patch, HTTPCLIENT-875.diff
>
>
> In the DefaultClientConnectionOperator function openConnection(...) it calls SocketFactory.connectSocket(...).
The documentation for connectSocket(...) says that it returns:
> "the connected socket. The returned object may be different from
> the sock argument if this factory supports a layered protocol. "
> A quick peek at the source showed:
> In org.apache.http.impl.conn.DefaultClientConnectionOperator:
> 117 final SocketFactory sf = schm.getSocketFactory();
> 118
> 119 Socket sock = sf.createSocket();
> 120 conn.opening(sock, target);
> 121
> 122 try {
> 123 sock = sf.connectSocket(sock, target.getHostName(),
> 124 schm.resolvePort(target.getPort()),
> 125 local, 0, params);
> 126 } catch (ConnectException ex) {
> 127 throw new HttpHostConnectException(target, ex);
> 128 }
> 129 prepareSocket(sock, context, params);
> 130 conn.openCompleted(sf.isSecure(sock), params);
> So DefaultClientConnectionOperator never updates conn with the new version of sock that
may have been returned from connectSocket(...).
> adding:
> 130 conn.openCompleted(sf.isSecure(sock), params);
> +++ 131 conn.update(sock, target, sf.isSecure(sock), params);
> appears to fix the issue.
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb moved COMMONSSITE-47 to HTTPCLIENT-897:
--------------------------------------------
Component/s: (was: Site)
HttpClient
Key: HTTPCLIENT-897 (was: COMMONSSITE-47)
Project: HttpComponents HttpClient (was: Commons All)
> java.lang.IllegalStateException: unsupported protocol: "<host name>" when using
ConnectMethod
> ---------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-897
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-897
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Environment: commons-httpclient-3.1.jar
> Reporter: Barry Silis
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> The method org.apache.commons.httpclient.ConnectMethod.getURI() omits the protocol from
the returned URI, causing an exception *java.lang.IllegalStateException* when trying to use
the class ConnectMethod.
> I believe it can be solved by not overriding org.apache.commons.httpclient.HttpMethodBase.getURI()
in the ConnectMethod class.
> The exception:
> Exception in thread "main" java.lang.IllegalStateException: unsupported protocol: 'www.google.com'
> at org.apache.commons.httpclient.protocol.Protocol.lazyRegisterProtocol(Protocol.java:149)
> at org.apache.commons.httpclient.protocol.Protocol.getProtocol(Protocol.java:117)
> at org.apache.commons.httpclient.HostConfiguration.setHost(HostConfiguration.java:253)
> at org.apache.commons.httpclient.HostConfiguration.setHost(HostConfiguration.java:315)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:388)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> at epicon.sbr.client.TestHttpGet.connectToProxy(TestHttpGet.java:293)
> at epicon.sbr.client.TestHttpGet.main(TestHttpGet.java:41)
> Cheers,
> Barry.
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
+1 (On the correct thread this time :) ) ...ant On Fri, Dec 4, 2009 at 10:40 AM, Oleg Kalnichevski <olegk@apache.org> wrote: > Please vote on releasing these packages as HttpComponents Client 4.1-alpha1. > The vote is open for at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: > http://people.apache.org/~olegk/httpclient-4.1-alpha1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.1-alpha1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1-alpha1/ > > -------------------------------------------------------------------------- > Vote: HttpComponents Client 4.1-alpha1 release > [ ] +1 Release the packages as HttpComponents Client 4.1-alpha1. > [ ] -1 I am against releasing the packages (must include a reason). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
+1 ...ant On Thu, Dec 3, 2009 at 10:57 PM, Oleg Kalnichevski <olegk@apache.org> wrote: > Please vote on releasing these packages as HttpComponents Client 4.0.1. > The vote is open for at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: http://people.apache.org/~olegk/httpclient-4.0.1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
Looks good to me, +1 ...ant On Thu, Dec 3, 2009 at 10:57 PM, Oleg Kalnichevski <olegk@apache.org> wrote: > Please vote on releasing these packages as HttpComponents Client 4.0.1. > The vote is open for at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: http://people.apache.org/~olegk/httpclient-4.0.1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
+1 asankha Oleg Kalnichevski wrote: > Please vote on releasing these packages as HttpComponents Client 4.0.1. > The vote is open for at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: http://people.apache.org/~olegk/httpclient-4.0.1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
> Vote: HttpComponents Client 4.1-alpha1 release > [X] +1 Release the packages as HttpComponents Client 4.1-alpha1. > [ ] -1 I am against releasing the packages (must include a reason). asankha --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
sebb wrote: > On 04/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: >> On Fri, 2009-12-04 at 00:34 +0000, sebb wrote: >> > On 03/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: >> > > On Thu, 2009-12-03 at 00:33 +0000, sebb wrote: >> > > > If possible, I'd suggest creating an RCn tag. If the vote passes, it >> > > > can be copied/renamed to the final tag. That allows the tag to be >> > > > immutable. >> > > > >> > > >> > > >> > > The trouble is that tagging a release of a maven project involves more >> > > than creating a SVN tag. >> > > >> > >> > Depends how much you allow Maven to do; there are certainly Commons >> > projects that are released this way, for example Pool. >> > >> >> >> This is not a matter of how much Maven is allowed to do. The problem is >> that by moving the tag you will end up with a mismatch between the tag >> name and the POM metadata. >> > > Commons Pool uses M2 but still uses RC tags so there must be a way to > do it without causing an incorrect POM. > There is a way but it involves more than just copying a SVN tag Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
On 04/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: > On Fri, 2009-12-04 at 00:34 +0000, sebb wrote: > > On 03/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: > > > On Thu, 2009-12-03 at 00:33 +0000, sebb wrote: > > > > If possible, I'd suggest creating an RCn tag. If the vote passes, it > > > > can be copied/renamed to the final tag. That allows the tag to be > > > > immutable. > > > > > > > > > > > > > The trouble is that tagging a release of a maven project involves more > > > than creating a SVN tag. > > > > > > > Depends how much you allow Maven to do; there are certainly Commons > > projects that are released this way, for example Pool. > > > > > This is not a matter of how much Maven is allowed to do. The problem is > that by moving the tag you will end up with a mismatch between the tag > name and the POM metadata. > Commons Pool uses M2 but still uses RC tags so there must be a way to do it without causing an incorrect POM. > Oleg > > > > > > > Oleg > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > > > For additional commands, e-mail: dev-help@hc.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > > For additional commands, e-mail: dev-help@hc.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Perkins reopened HTTPCLIENT-862:
------------------------------------
Oleg,
I finally got a chance to test the new RedirectStrategy interface. It does give me the flexibility
I need, but there's an implementation issue relating to entity enclosing methods like PUT
and POST.
In DefaultRequestDirector.handleResponse (currently line 1008), the code does this:
RequestWrapper wrapper = new RequestWrapper(redirect);
wrapper.setParams(params);
But in HttpRequestExecutor.doSendRequest (currently line 213), the code has this check:
if (request instanceof HttpEntityEnclosingRequest) {
Because a RequestWrapper is not an HttpEntityEnclosingRequest, we'll never enter this on a
redirect. And if we don't enter this, we'll never emit the entity body. This means that
even though I can use the new interfaces to cause the client to follow a POST redirect with
a POST, I can't get the payload to be sent when the redirect is followed.
It appears that if handleResponse created an EntityEnclosingRequestWrapper when the redirect
object is a PUT or POST, it would solve this problem.
Thoughts?
Thanks again.
Ben
> 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
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[x] +1 Release the packages as HttpComponents Client 4.1-alpha1. Oleg Kalnichevski wrote: > Please vote on releasing these packages as HttpComponents Client > 4.1-alpha1. The vote is open for at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: > http://people.apache.org/~olegk/httpclient-4.1-alpha1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.1-alpha1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1-alpha1/ > > -------------------------------------------------------------------------- > Vote: HttpComponents Client 4.1-alpha1 release > [ ] +1 Release the packages as HttpComponents Client 4.1-alpha1. > [ ] -1 I am against releasing the packages (must include a reason). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
Please vote on releasing these packages as HttpComponents Client 4.1-alpha1. The vote is open for at least 72 hours, and only votes from HttpComponents PMC members are binding. The vote passes if at least three binding +1 votes are cast and there are more +1 than -1 votes. Packages: http://people.apache.org/~olegk/httpclient-4.1-alpha1/ Release notes: http://people.apache.org/~olegk/httpclient-4.1-alpha1/RELEASE_NOTES.txt SVN tag: http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.1-alpha1/ -------------------------------------------------------------------------- Vote: HttpComponents Client 4.1-alpha1 release [ ] +1 Release the packages as HttpComponents Client 4.1-alpha1. [ ] -1 I am against releasing the packages (must include a reason). --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
On Fri, 2009-12-04 at 00:34 +0000, sebb wrote: > On 03/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: > > On Thu, 2009-12-03 at 00:33 +0000, sebb wrote: > > > If possible, I'd suggest creating an RCn tag. If the vote passes, it > > > can be copied/renamed to the final tag. That allows the tag to be > > > immutable. > > > > > > > > > The trouble is that tagging a release of a maven project involves more > > than creating a SVN tag. > > > > Depends how much you allow Maven to do; there are certainly Commons > projects that are released this way, for example Pool. > This is not a matter of how much Maven is allowed to do. The problem is that by moving the tag you will end up with a mismatch between the tag name and the POM metadata. Oleg > > Oleg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > > For additional commands, e-mail: dev-help@hc.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
On 03/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: > Please vote on releasing these packages as HttpComponents Client 4.0.1. Sorry, I won't be able to check the release until Mon evening at the earliest. > The vote is open for at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: http://people.apache.org/~olegk/httpclient-4.0.1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
On 03/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: > On Thu, 2009-12-03 at 00:33 +0000, sebb wrote: > > If possible, I'd suggest creating an RCn tag. If the vote passes, it > > can be copied/renamed to the final tag. That allows the tag to be > > immutable. > > > > > The trouble is that tagging a release of a maven project involves more > than creating a SVN tag. > Depends how much you allow Maven to do; there are certainly Commons projects that are released this way, for example Pool. > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
+1 Oleg On Thu, 2009-12-03 at 23:57 +0100, Oleg Kalnichevski wrote: > Please vote on releasing these packages as HttpComponents Client 4.0.1. > The vote is open for at least 72 hours, and only votes from > HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: http://people.apache.org/~olegk/httpclient-4.0.1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
Please vote on releasing these packages as HttpComponents Client 4.0.1. The vote is open for at least 72 hours, and only votes from HttpComponents PMC members are binding. The vote passes if at least three binding +1 votes are cast and there are more +1 than -1 votes. Packages: http://people.apache.org/~olegk/httpclient-4.0.1/ Release notes: http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt SVN tag: http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785384#action_12785384
]
Fuad Efendi edited comment on HTTPCLIENT-896 at 12/3/09 4:37 PM:
-----------------------------------------------------------------
The only difference is comma after day of week...
Thank you very much Oleg!
So, it is configurable, nothing to fix.
was (Author: funtick):
The only difference is comma after day of week...
> CLONE -Parsing expires
> ----------------------
>
> Key: HTTPCLIENT-896
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-896
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCookie
> Reporter: Fuad Efendi
>
> Seeing this very often:
> Invalid cookie header: "Set-Cookie: _asid=011e7014f5e7718e02d893335aa5a16e; path=/;
expires=Wed, 16 May 2018 17:13:32 GMT". Unable to parse expires attribute: Wed, 16 May 2018
17:13:32 GMT
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785384#action_12785384
]
Fuad Efendi commented on HTTPCLIENT-896:
----------------------------------------
The only difference is comma after day of week...
> CLONE -Parsing expires
> ----------------------
>
> Key: HTTPCLIENT-896
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-896
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCookie
> Reporter: Fuad Efendi
>
> Seeing this very often:
> Invalid cookie header: "Set-Cookie: _asid=011e7014f5e7718e02d893335aa5a16e; path=/;
expires=Wed, 16 May 2018 17:13:32 GMT". Unable to parse expires attribute: Wed, 16 May 2018
17:13:32 GMT
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
On Thu, 2009-12-03 at 00:33 +0000, sebb wrote: > If possible, I'd suggest creating an RCn tag. If the vote passes, it > can be copied/renamed to the final tag. That allows the tag to be > immutable. > The trouble is that tagging a release of a maven project involves more than creating a SVN tag. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-896.
------------------------------------------
Resolution: Won't Fix
The format of the cookie in question is compatible with the Netscape Draft specification only.
The best match cookie policy correctly identifies the cookie as Netscape but parsing of the
'expires' attribute fails because the only date format permitted by the Netscape Draft is
"EEE, dd MMM-yyyy-HH:mm:ss z". In order to make HttpClient accept cookies containing nonstandard
'expires' one should set valid date formats using 'http.protocol.cookie-datepatterns' parameter.
See example:
-----
BasicHttpParams params = new BasicHttpParams();
params.setParameter(CookieSpecPNames.DATE_PATTERNS,
Arrays.asList("EEE, dd MMM-yyyy-HH:mm:ss z", "EEE, dd MMM yyyy HH:mm:ss z"));
BestMatchSpecFactory factory = new BestMatchSpecFactory();
CookieSpec cookiespec = factory.newInstance(params);
BasicHeader header = new BasicHeader("Set-Cookie",
"asid=011e7014f5e7718e02d893335aa5a16e; path=/; " +
"expires=Wed, 16 May 2018 17:13:32 GMT");
CookieOrigin origin = new CookieOrigin("localhost", 80, "/", false);
List<Cookie> cookies = cookiespec.parse(header, origin);
System.out.println(cookies);
-----
I guess the policy was made stricter sometime post 4.0-beta1
Hope this clarifies the situation somewhat
Oleg
> CLONE -Parsing expires
> ----------------------
>
> Key: HTTPCLIENT-896
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-896
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCookie
> Reporter: Fuad Efendi
>
> Seeing this very often:
> Invalid cookie header: "Set-Cookie: _asid=011e7014f5e7718e02d893335aa5a16e; path=/;
expires=Wed, 16 May 2018 17:13:32 GMT". Unable to parse expires attribute: Wed, 16 May 2018
17:13:32 GMT
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785148#action_12785148
]
Fuad Efendi commented on HTTPCLIENT-896:
----------------------------------------
I still see this problem in version 4.0 (loaded by Maven from Maven repository).
And I don't see this problem with version 4.0-beta3-SNAPSHOT (loaded by Maven from Apache
repository).
09/12/02 21:01:31 WARN protocol.ResponseProcessCookies: Invalid cookie header: "Set-cookie:
session-id-time=1260345600l; path=/; domain=.amazon.com; expires=Wed
Dec 09 08:00:00 2009 GMT". Unable to parse expires attribute: Wed Dec 09 08:00:00 2009 GMT
09/12/02 21:01:31 WARN protocol.ResponseProcessCookies: Invalid cookie header: "Set-cookie:
session-id=192-5799048-2819311; path=/; domain=.amazon.com; expires=
Wed Dec 09 08:00:00 2009 GMT". Unable to parse expires attribute: Wed Dec 09 08:00:00 2009
GMT
> CLONE -Parsing expires
> ----------------------
>
> Key: HTTPCLIENT-896
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-896
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCookie
> Reporter: Fuad Efendi
>
> Seeing this very often:
> Invalid cookie header: "Set-Cookie: _asid=011e7014f5e7718e02d893335aa5a16e; path=/;
expires=Wed, 16 May 2018 17:13:32 GMT". Unable to parse expires attribute: Wed, 16 May 2018
17:13:32 GMT
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
CLONE -Parsing expires
----------------------
Key: HTTPCLIENT-896
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-896
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpCookie
Reporter: Fuad Efendi
Seeing this very often:
Invalid cookie header: "Set-Cookie: _asid=011e7014f5e7718e02d893335aa5a16e; path=/; expires=Wed,
16 May 2018 17:13:32 GMT". Unable to parse expires attribute: Wed, 16 May 2018 17:13:32 GMT
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
If possible, I'd suggest creating an RCn tag. If the vote passes, it can be copied/renamed to the final tag. That allows the tag to be immutable. On 02/12/2009, Oleg Kalnichevski <olegk@apache.org> wrote: > Release vote called off. I screwed up while building release packages. > Too tired right now. > > Oleg > > On Wed, 2009-12-02 at 23:03 +0100, Oleg Kalnichevski wrote: > > Please vote on releasing these packages as HttpComponents Client 4.0.1. The vote is open for at least > > 72 hours, and only votes from HttpComponents PMC members are binding. The vote passes if at least > > three binding +1 votes are cast and there are more +1 than -1 votes. > > > > Packages: > > http://people.apache.org/~olegk/httpclient-4.0.1/ > > > > Release notes: > > http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt > > > > SVN tag: > > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ > > > > -------------------------------------------------------------------------- > > Vote: HttpComponents Client 4.0.1 release > > [ ] +1 Release the packages as HttpComponents Client 4.0.1. > > [ ] -1 I am against releasing the packages (must include a reason). > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > > For additional commands, e-mail: dev-help@hc.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
Release vote called off. I screwed up while building release packages. Too tired right now. Oleg On Wed, 2009-12-02 at 23:03 +0100, Oleg Kalnichevski wrote: > Please vote on releasing these packages as HttpComponents Client 4.0.1. The vote is open for at least > 72 hours, and only votes from HttpComponents PMC members are binding. The vote passes if at least > three binding +1 votes are cast and there are more +1 than -1 votes. > > Packages: > http://people.apache.org/~olegk/httpclient-4.0.1/ > > Release notes: > http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt > > SVN tag: > http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ > > -------------------------------------------------------------------------- > Vote: HttpComponents Client 4.0.1 release > [ ] +1 Release the packages as HttpComponents Client 4.0.1. > [ ] -1 I am against releasing the packages (must include a reason). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org > For additional commands, e-mail: dev-help@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
Please vote on releasing these packages as HttpComponents Client 4.0.1. The vote is open for at least 72 hours, and only votes from HttpComponents PMC members are binding. The vote passes if at least three binding +1 votes are cast and there are more +1 than -1 votes. Packages: http://people.apache.org/~olegk/httpclient-4.0.1/ Release notes: http://people.apache.org/~olegk/httpclient-4.0.1/RELEASE_NOTES.txt SVN tag: http://svn.apache.org/repos/asf/httpcomponents/httpclient/tags/4.0.1/ -------------------------------------------------------------------------- Vote: HttpComponents Client 4.0.1 release [ ] +1 Release the packages as HttpComponents Client 4.0.1. [ ] -1 I am against releasing the packages (must include a reason). --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-895.
------------------------------------------
Resolution: Fixed
Fixed in SVN trunk and 4.0.x branch. Please review / test
Oleg
> Log creation impairs performance
> --------------------------------
>
> Key: HTTPCLIENT-895
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Tony Poppleton
> Fix For: 4.0.1, 4.1 Alpha1
>
> Attachments: HTTPCLIENT-895.patch
>
>
> Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager,
revealed that 5% of the time was spent constructing Log instances in class ClientParamsStack.
> Oleg did some further investigation and found that DefaultRequestDirector also has the
same problem.
> A simple solution would be to make the Log a static member variable, and do this on all
classes for consistency. However this might not be the best solution for interoperating with
some frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
> Another solution would be to simply remove the Log from the affected classes, although
they are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-895:
-----------------------------------------
Priority: Major (was: Minor)
Fix Version/s: 4.1 Alpha1
4.0.1
> Log creation impairs performance
> --------------------------------
>
> Key: HTTPCLIENT-895
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Tony Poppleton
> Fix For: 4.0.1, 4.1 Alpha1
>
> Attachments: HTTPCLIENT-895.patch
>
>
> Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager,
revealed that 5% of the time was spent constructing Log instances in class ClientParamsStack.
> Oleg did some further investigation and found that DefaultRequestDirector also has the
same problem.
> A simple solution would be to make the Log a static member variable, and do this on all
classes for consistency. However this might not be the best solution for interoperating with
some frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
> Another solution would be to simply remove the Log from the affected classes, although
they are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783973#action_12783973
]
Tony Poppleton commented on HTTPCLIENT-895:
-------------------------------------------
Oops regarding the last comment - I had checked out the 4.0 tag rather than the trunk which
is why the patch didn't apply smoothly...
> Log creation impairs performance
> --------------------------------
>
> Key: HTTPCLIENT-895
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Tony Poppleton
> Priority: Minor
> Attachments: HTTPCLIENT-895.patch
>
>
> Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager,
revealed that 5% of the time was spent constructing Log instances in class ClientParamsStack.
> Oleg did some further investigation and found that DefaultRequestDirector also has the
same problem.
> A simple solution would be to make the Log a static member variable, and do this on all
classes for consistency. However this might not be the best solution for interoperating with
some frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
> Another solution would be to simply remove the Log from the affected classes, although
they are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783964#action_12783964
]
Tony Poppleton commented on HTTPCLIENT-895:
-------------------------------------------
The patch is for DefaultRequestDirector.java (revision 885491) and fails to apply properly
(needs manual fixing) as the revision I just got from SVN is 885603. Please advise.
When I ran my manually patched version there was a performance improvement on a small number
of benchmarks I ran (I am seeing upto 10% improvement in my threads dealing with responses).
> Log creation impairs performance
> --------------------------------
>
> Key: HTTPCLIENT-895
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Tony Poppleton
> Priority: Minor
> Attachments: HTTPCLIENT-895.patch
>
>
> Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager,
revealed that 5% of the time was spent constructing Log instances in class ClientParamsStack.
> Oleg did some further investigation and found that DefaultRequestDirector also has the
same problem.
> A simple solution would be to make the Log a static member variable, and do this on all
classes for consistency. However this might not be the best solution for interoperating with
some frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
> Another solution would be to simply remove the Log from the affected classes, although
they are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783874#action_12783874
]
Oleg Kalnichevski commented on HTTPCLIENT-895:
----------------------------------------------
I do not think that reverting back to using static logs would be such a good idea. We just
need to make sure that no Log object lookups take place on critical execution paths. That
is, there no Log objects should be created on a per request basis. Objects created in the
course of request execution should be reusing Log object of the HttpClient instance.
Oleg
> Log creation impairs performance
> --------------------------------
>
> Key: HTTPCLIENT-895
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Tony Poppleton
> Priority: Minor
> Attachments: HTTPCLIENT-895.patch
>
>
> Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager,
revealed that 5% of the time was spent constructing Log instances in class ClientParamsStack.
> Oleg did some further investigation and found that DefaultRequestDirector also has the
same problem.
> A simple solution would be to make the Log a static member variable, and do this on all
classes for consistency. However this might not be the best solution for interoperating with
some frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
> Another solution would be to simply remove the Log from the affected classes, although
they are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-895:
-----------------------------------------
Attachment: HTTPCLIENT-895.patch
Tony,
Could you please test the patch? You will need the latest SVN snapshot to apply it.
Oleg
> Log creation impairs performance
> --------------------------------
>
> Key: HTTPCLIENT-895
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Tony Poppleton
> Priority: Minor
> Attachments: HTTPCLIENT-895.patch
>
>
> Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager,
revealed that 5% of the time was spent constructing Log instances in class ClientParamsStack.
> Oleg did some further investigation and found that DefaultRequestDirector also has the
same problem.
> A simple solution would be to make the Log a static member variable, and do this on all
classes for consistency. However this might not be the best solution for interoperating with
some frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
> Another solution would be to simply remove the Log from the affected classes, although
they are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[ https://issues.apache.org/jira/browse/HTTPCLIENT-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783838#action_12783838
]
Tony Poppleton commented on HTTPCLIENT-895:
-------------------------------------------
The second solution would also mean that there is a risk this bug might resurface in the future,
either in the same class or in another part of the library by the introduction of a Log.
So the "static" solution would be better in this respect.
> Log creation impairs performance
> --------------------------------
>
> Key: HTTPCLIENT-895
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 4.0 Final
> Reporter: Tony Poppleton
> Priority: Minor
>
> Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager,
revealed that 5% of the time was spent constructing Log instances in class ClientParamsStack.
> Oleg did some further investigation and found that DefaultRequestDirector also has the
same problem.
> A simple solution would be to make the Log a static member variable, and do this on all
classes for consistency. However this might not be the best solution for interoperating with
some frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
> Another solution would be to simply remove the Log from the affected classes, although
they are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Log creation impairs performance
--------------------------------
Key: HTTPCLIENT-895
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-895
Project: HttpComponents HttpClient
Issue Type: Improvement
Components: HttpClient
Affects Versions: 4.0 Final
Reporter: Tony Poppleton
Priority: Minor
Running JProfiler on a program that uses HttpClient with a ThreadSafeClientConnManager, revealed
that 5% of the time was spent constructing Log instances in class ClientParamsStack.
Oleg did some further investigation and found that DefaultRequestDirector also has the same
problem.
A simple solution would be to make the Log a static member variable, and do this on all classes
for consistency. However this might not be the best solution for interoperating with some
frameworks (see http://wiki.apache.org/jakarta-commons/Logging/StaticLog)
Another solution would be to simply remove the Log from the affected classes, although they
are presumably there for a reason...
--
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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change
notification.
The "HttpClientPowered" page has been changed by mendelson.
http://wiki.apache.org/jakarta-httpclient/HttpClientPowered?action=diff&rev1=29&rev2=30
--------------------------------------------------
[[http://sourceforge.net/projects/hippojump|Hippojump]]
Hippojump is an open-source project that hosts a Eclipse RCP-based news/data aggregator
that captures different data sources such as RSS, XML, HTML, web services and allows the user
to set keywords filter on the data and also set the delivery mode of the data, such as browser,
email, SMS, etc.
- [[http://www.mendelson-e-c.com/products_mec_as2.php|m-e-c as2]]
+ [[http://opensource.mendelson-e-c.com/|mendelson opensource AS2]]
- m-e-c as2 is an open source [[http://en.wikipedia.org/wiki/Electronic_Data_Interchange|EDI]]INT
[[http://en.wikipedia.org/wiki/AS2|AS2]] implemenation. It contains a comfortable logging-
and configuration GUI that helps you managing your transactions. It supports asynchronous
and synchronous MDN, digital signatures, encryption, SSL.
+ mendelson open source AS2 is a free EDIINT [[http://en.wikipedia.org/wiki/AS2|AS2]]
implemenation. It contains a comfortable logging- and configuration GUI that helps you managing
your transactions. It supports asynchronous and synchronous MDN, digital signatures, encryption,
SSL.
[[http://www.restlet.org|Restlet]]
Restlet, a lightweight REST framework for Java, natively supports the Jakarta Commons
HTTP Client. It is available as a pluggable alternative to our other HTTP client connector
based on JDK's HttpURLConnection. It adds an abstraction layer over Jakarta HTTP Client and
allow Restlet applications to transparently switch between several implementations without
modifying a single line of code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
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@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org
[ 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@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org