Nabble - HttpComponents-Dev

[jira] Closed: (HTTPCLIENT-888) About Proxy Tunneling + HTTPS

2009-11-09T06:08:33Z

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

Ortwin Glück closed HTTPCLIENT-888.
-----------------------------------

Resolution: Invalid

THIS IS THE WRONG PLACE TO ASK QUESTIONS. You will not get any answer here. Please stop going on everybody's nerves.

Please use the mailing lists: http://hc.apache.org/mail.html

> About Proxy Tunneling + HTTPS
> -----------------------------
>
> Key: HTTPCLIENT-888
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-888
> Project: HttpComponents HttpClient
> Issue Type: Question
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: WIn
> Reporter: Space
> Fix For: 4.0 Final
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> I need to connect to a Server which has enabled SSL .So I need to download certificates before making connection to the server.How to do that using HttpClinet.I read the document it has given way for SSL and Proxy but not for downloading certifictaes

--
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-888) About Proxy Tunneling + HTTPS

2009-11-09T03:38:32Z

About Proxy Tunneling + HTTPS
-----------------------------

Key: HTTPCLIENT-888
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-888
Project: HttpComponents HttpClient
Issue Type: Question
Components: HttpClient
Affects Versions: 4.0 Final
Environment: WIn
Reporter: Space
Fix For: 4.0 Final

I need to connect to a Server which has enabled SSL .So I need to download certificates before making connection to the server.How to do that using HttpClinet.I read the document it has given way for SSL and Proxy but not for downloading certifictaes

--
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] Deleted: (HTTPCLIENT-887) I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?

2009-11-09T03:14:32Z

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

Ortwin Glück deleted HTTPCLIENT-887:
------------------------------------

> I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?
> -------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-887
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-887
> Project: HttpComponents HttpClient
> Issue Type: Question
> Environment: Java
> Reporter: Space
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?

[jira] Resolved: (HTTPCLIENT-887) I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?

2009-11-09T03:10:32Z

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

Ortwin Glück resolved HTTPCLIENT-887.
-------------------------------------

Resolution: Invalid

This is not a forum or chatroom. Please use the mailing lists:
http://hc.apache.org/mail.html

> I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?
> -------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-887
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-887
> Project: HttpComponents HttpClient
> Issue Type: Question
> Components: HttpClient
> Affects Versions: 4.0 Final
> Environment: Java
> Reporter: Space
> Fix For: 4.0 Final
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?

[jira] Created: (HTTPCLIENT-887) I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?

2009-11-09T02:58:32Z

I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?
-------------------------------------------------------------------------------------------------------

Key: HTTPCLIENT-887
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-887
Project: HttpComponents HttpClient
Issue Type: Question
Components: HttpClient
Affects Versions: 4.0 Final
Environment: Java
Reporter: Space
Fix For: 4.0 Final

I need to get certificates from the server through proxy connection ? How to use HttpClinet for that ?

--
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@...

Re: @SuppressWarnings("null") really needed?

2009-11-06T09:06:51Z

Eclipse 3.4 & 3.5 changed the way they handle warnings. For example, in 3.4
a private inner class with unused public variables would not warn about
unused variables. In 3.5, it does warn (and adding a suppression for 3.5
will cause 3.4 to warn about an unnecessary suppression). I assume there's
similar changes for null handling.

Sam

On Fri, Nov 6, 2009 at 11:47 AM, sebb <sebbaz@...> wrote:

> Well, without it _I_ get a warning that the variable could be null...
>
> I assume we must have different local Eclipse settings.
>
> Not sure how to deal with the problem - seems to me Eclipse is being
> too literal about the warning in your case.
>
> ==
>
> I found these regarding the annotation:
>
>
> http://knol.google.com/k/alex-miller/suppresswarnings-annotation-in-java/1f092vcri65lh/3#
>
>
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm
>
> On 06/11/2009, Oleg Kalnichevski <olegk@...> wrote:
> > Hi Sebastian,
> >
> > Since your last commit my Eclipse pops up a warning saying 'Unnecessary
> > @SuppressWarnings("null")'. What is the purpose of this annotation? Is it
> > needed?
> >
> > 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: @SuppressWarnings("null") really needed?

2009-11-06T08:47:50Z

Well, without it _I_ get a warning that the variable could be null...

I assume we must have different local Eclipse settings.

Not sure how to deal with the problem - seems to me Eclipse is being
too literal about the warning in your case.

==

I found these regarding the annotation:

http://knol.google.com/k/alex-miller/suppresswarnings-annotation-in-java/1f092vcri65lh/3#

http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm

On 06/11/2009, Oleg Kalnichevski <olegk@...> wrote:

> Hi Sebastian,
>
> Since your last commit my Eclipse pops up a warning saying 'Unnecessary
> @SuppressWarnings("null")'. What is the purpose of this annotation? Is it
> needed?
>
> 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@...

@SuppressWarnings("null") really needed?

2009-11-06T08:29:47Z

Hi Sebastian,

Since your last commit my Eclipse pops up a warning saying 'Unnecessary
@SuppressWarnings("null")'. What is the purpose of this annotation? Is
it needed?

Oleg

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

[jira] Commented: (HTTPCORE-155) Performance issues with IBM JRE 6.0

2009-11-04T12:03:32Z

[ https://issues.apache.org/jira/browse/HTTPCORE-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773629#action_12773629 ]

Oleg Kalnichevski commented on HTTPCORE-155:
--------------------------------------------

It looks like IBM fixed the problem in its code, making this workaround less relevant.

http://www-01.ibm.com/support/docview.wss?uid=swg1IZ31216

It would be great if someone could test HttpCore with IBM Java 5.0.0 SR9 or SR10

Oleg

> Performance issues with IBM JRE 6.0
> -----------------------------------
>
> Key: HTTPCORE-155
> URL: https://issues.apache.org/jira/browse/HTTPCORE-155
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.0-beta1
> Environment: Windows 2003 SP2 - IBM J2RE 1.6.0 build 2.4 - HTTPCore Beta1 - Dual Core CPU 3.0Ghz - 1Gbps networking
> Reporter: Tom McSorley
> Fix For: 4.1-alpha1
>
> Attachments: AbstractIOReactor.diff, AbstractIOReactor.java, brush_up_1.09-03-20, HTTPCORE-155.patch, IOSessionImpl.diff, IOSessionImpl.java, javacore.20081203.153723.32300.0001.txt, myoutput.txt, patch.08-12-17.tar.gz, patch.08-12-18.tar.gz, patch.08-12-22.tar.gz, patch.08-12-30.tar.gz, patch.09-03-18.tar.gz, summary_patch.09-03-18
>
>
> I'm issuing a second HTTP Request on a connection that has very recently returned a null for the submitRequest() call... this 2nd request is being issued approximately 500ms after the submitRequest() null is returned... so the connection has just been established, an HTTP Request/Response-200 cycle has completed just prior to this 2nd request being issued. I'm seeing unusually long delays in the requestOutput() call (verified by surrounding timing prints)... that can range anywhere from a few milliseconds on up to 60 seconds... It eventually unwinds, and then the submitRequest() is called... this 2nd request is dispatched and works fine... but, it is delayed considerably... Is this a known issue and is there a possible work-around?
> Here's the JVM related thread information:
> The thread being delayed and stuck in the requestOutput() call for a long time (mostly longer than 5 seconds):
> 3XMTHREADINFO "pool-2-thread-5" TID:0x2AEECE00, j9thread_t:0x2A7189A8, state:B, prio=5
> 3XMTHREADINFO1 (native thread ID:0x1B44, native priority:0x5, native policy:UNKNOWN)
> 4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.interestOps(SelectionKeyImpl.java:60)
> 4XESTACKTRACE at org/apache/http/impl/nio/reactor/IOSessionImpl.setEvent(IOSessionImpl.java:113)
> 4XESTACKTRACE at org/apache/http/impl/nio/NHttpConnectionBase.requestOutput(NHttpConnectionBase.java:158)
> .... (non important stack information removed)
> 4XESTACKTRACE at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
> 4XESTACKTRACE at java/lang/Thread.run(Thread.java:735)
> Here's the monitor that this thread is blocked and waiting on:
> 2LKMONINUSE sys_mon_t:0x2A708AF8 infl_mon_t: 0x2A708B30:
> 3LKMONOBJECT sun/nio/ch/Util$1@00B09208/00B09214: Flat locked by "I/O dispatcher 7" (0x2A208E00), entry count 1
> 3LKWAITERQ Waiting to enter:
> 3LKWAITER "pool-2-thread-5" (0x2AEECE00)
> And here's the thread that currently has this monitor locked:
> 3XMTHREADINFO "I/O dispatcher 7" TID:0x2A208E00, j9thread_t:0x2A6EC73C, state:R, prio=5
> 3XMTHREADINFO1 (native thread ID:0x830, native priority:0x5, native policy:UNKNOWN)
> 4XESTACKTRACE at sun/nio/ch/WindowsSelectorImpl$SubSelector.poll0(Native Method)
> 4XESTACKTRACE at sun/nio/ch/WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:308(Compiled Code))
> 4XESTACKTRACE at sun/nio/ch/WindowsSelectorImpl$SubSelector.access$500(WindowsSelectorImpl.java(Compiled Code))
> 4XESTACKTRACE at sun/nio/ch/WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:162(Compiled Code))
> 4XESTACKTRACE at sun/nio/ch/SelectorImpl.lockAndDoSelect(SelectorImpl.java:69(Compiled Code))
> 4XESTACKTRACE at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:80(Compiled Code))
> 4XESTACKTRACE at org/apache/http/impl/nio/reactor/AbstractIOReactor.execute(AbstractIOReactor.java:121)
> 4XESTACKTRACE at org/apache/http/impl/nio/reactor/BaseIOReactor.execute(BaseIOReactor.java:70)
> 4XESTACKTRACE at org/apache/http/impl/nio/reactor/AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:318)
> 4XESTACKTRACE at java/lang/Thread.run(Thread.java:735)
> I should also note that we're attempting to use 1000 client instances on this single system... each with potentially 2 active connections simultaneously... there is also virtually no CPU load (i.e. less then 5%) on this system...

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

2009-11-04T11:59:32Z

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

Oleg Kalnichevski resolved HTTPCLIENT-885.
------------------------------------------

Resolution: Fixed

Fixed in SVN trunk and 4.0.x branch. Please review / re-test

Oleg

> 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-884) Charset omitted from UrlEncodedFormEntity Content-Type header

2009-11-04T11:59:32Z

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

Oleg Kalnichevski resolved HTTPCLIENT-884.
------------------------------------------

Resolution: Fixed

Patch checked in to SVN trunk and 4.0.x branch. Please review / re-test

Many thanks for submitting the patch, Jared

Oleg

> 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);
> }

[jira] Resolved: (HTTPCLIENT-834) Transparent Content Coding support

2009-11-04T11:27:32Z

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

Oleg Kalnichevski resolved HTTPCLIENT-834.
------------------------------------------

Resolution: Fixed

Patch checked in. Many thanks, James

Oleg

> Transparent Content Coding support
> ----------------------------------
>
> Key: HTTPCLIENT-834
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-834
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient
> Affects Versions: 4.0 Beta 2
> Environment: Any
> Reporter: James Abley
> Fix For: 4.1 Alpha1
>
> Attachments: 834-2009-03-17.patch, 834-docbook.patch, 834-svn-754998.patch, 834-svn-r811556.patch, 834-svn-r814881.patch, 834-svn-r815739.patch, 834-svn-r816185.patch, 834-svn-r832534-write-to.patch, disable-content-coding.patch
>
>
> I would like to see HttpClient features brought up to parity with other libraries, both in Java and other languages. c.f. Python's httplib2 (not yet in the standard library, but many would like to see it in there). That library transparently handles gzip and compress content codings.
> This issue is to capture possible solutions to providing this sort of innate functionality in HttpClient, so that users aren't required to know RFC2616 intimately. The HttpClient library should do the right thing and use the network in the most efficient manner possible.

[jira] Commented: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T07:27:32Z

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

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

Feel free to implement your own retry handler. That's why it's customizable.

> Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
> ------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 3.1 Final
> Reporter: Sylvain Laurent
>
> We have a buggy load-balancer that sometimes forwards the request to the back-end server, and then close the connections without returning any data at all.
> This provokes a NoHttpResponseException inside commons http client 3.1, which is handled by DefaultHttpMethodRetryHandler.
> Unfortunately DefaultHttpMethodRetryHandler handles this NoHttpResponseException by asking for a retry. In our case, this is very dangerous because the request has already been sent and is being processed by the back-end server.
> I think that in the case of a NoHttpResponseException the test !method.isRequestSent() shoud be done :
> if (exception instanceof NoHttpResponseException && !method.isRequestSent()) {
> // Retry if the server dropped connection on us AND the request was not sent
> return true;
> }

[jira] Commented: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T07:23:32Z

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

Sylvain Laurent commented on HTTPCLIENT-886:
--------------------------------------------

I understand the fact that there are no longer any bug-fix for 3.x.

I cannot test with 4.x at the moment, but I definitely think that http client should NOT retry in such a case, regardless of the application and its intended usage of http protocol...

Sylvain

[jira] Resolved: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T06:49:32Z

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

Oleg Kalnichevski resolved HTTPCLIENT-886.
------------------------------------------

Resolution: Invalid

(1) There will be no fixes to HttpClient 3.x other than for severe security related issues. Please do not re-open the issue unless the problem can be reproduced with HttpClient 4.0

(2) It is not a problem of HttpClient if your application abuses HTTP protocol for something it has never been intended for, such as transaction processing.

Oleg

[jira] Commented: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T06:31:32Z

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

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

NoHttpResponseException is only ever thrown (from readStatusLine()) after the response has been sent. So the conditon would never be true, actually. Can we think of ANY scenario where retrying is the right thing to do when we get no response from the server?

[jira] Updated: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T06:05:32Z

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

Sylvain Laurent updated HTTPCLIENT-886:
---------------------------------------

Priority: Major (was: Critical)

[jira] Reopened: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T06:05:32Z

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

Sylvain Laurent reopened HTTPCLIENT-886:
----------------------------------------

[jira] Commented: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T05:45:32Z

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

Sylvain Laurent commented on HTTPCLIENT-886:
--------------------------------------------

I agree with you about implementing detection for duplicate, but I don't agree that the behavior in case of NoHttpResponseException should be to retry. As my case shows, there is a possibility that the request was actually sent to the back-end, so no retry should be attempted (better safe than sorry).
In the case of a java.net.ConnectException it' safe to retry because the client did not send the request, and we are sure of it.

> Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
> ------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 3.1 Final
> Reporter: Sylvain Laurent
> Priority: Critical
>
> We have a buggy load-balancer that sometimes forwards the request to the back-end server, and then close the connections without returning any data at all.
> This provokes a NoHttpResponseException inside commons http client 3.1, which is handled by DefaultHttpMethodRetryHandler.
> Unfortunately DefaultHttpMethodRetryHandler handles this NoHttpResponseException by asking for a retry. In our case, this is very dangerous because the request has already been sent and is being processed by the back-end server.
> I think that in the case of a NoHttpResponseException the test !method.isRequestSent() shoud be done :
> if (exception instanceof NoHttpResponseException && !method.isRequestSent()) {
> // Retry if the server dropped connection on us AND the request was not sent
> return true;
> }

[jira] Resolved: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T05:25:32Z

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

Ortwin Glück resolved HTTPCLIENT-886.
-------------------------------------

Resolution: Invalid

isRequestSent() doesn't mean that the request has actually reached the server.

> Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
> ------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 3.1 Final
> Reporter: Sylvain Laurent
> Priority: Critical
> Fix For: 3.1.1
>
>
> We have a buggy load-balancer that sometimes forwards the request to the back-end server, and then close the connections without returning any data at all.
> This provokes a NoHttpResponseException inside commons http client 3.1, which is handled by DefaultHttpMethodRetryHandler.
> Unfortunately DefaultHttpMethodRetryHandler handles this NoHttpResponseException by asking for a retry. In our case, this is very dangerous because the request has already been sent and is being processed by the back-end server.
> I think that in the case of a NoHttpResponseException the test !method.isRequestSent() shoud be done :
> if (exception instanceof NoHttpResponseException && !method.isRequestSent()) {
> // Retry if the server dropped connection on us AND the request was not sent
> return true;
> }

[jira] Updated: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T05:25:32Z

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

Ortwin Glück updated HTTPCLIENT-886:
------------------------------------

Fix Version/s: (was: 3.1.1)

> Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
> ------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 3.1 Final
> Reporter: Sylvain Laurent
> Priority: Critical
>
> We have a buggy load-balancer that sometimes forwards the request to the back-end server, and then close the connections without returning any data at all.
> This provokes a NoHttpResponseException inside commons http client 3.1, which is handled by DefaultHttpMethodRetryHandler.
> Unfortunately DefaultHttpMethodRetryHandler handles this NoHttpResponseException by asking for a retry. In our case, this is very dangerous because the request has already been sent and is being processed by the back-end server.
> I think that in the case of a NoHttpResponseException the test !method.isRequestSent() shoud be done :
> if (exception instanceof NoHttpResponseException && !method.isRequestSent()) {
> // Retry if the server dropped connection on us AND the request was not sent
> return true;
> }

[jira] Commented: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T05:23:32Z

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

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

> In our case, this is very dangerous because the request has already been sent and is being processed by the back-end server.

If a repeated request is "very dangerous" you'd better implementing detection for duplicate requests in your application! Use challenge/reponse tokens, sequence numbers, timestamps or other means to detect repeated requests. The behaviour of HttpClient is not the only source for repeated requests. Messaging over any unreliable medium (like a network) ALWAYS has to make the choice between either loosing some messages, or accepting and dealing with duplicates. This is a fundamental theorem. It's the reason for why there is UDP and TCP and their different guarantees.

If the client doesn't get a response it can never know whether the request didn't reach the server or the response just didn't reach the client. By not retrying the request, the client risks that the request never reached the destination. It HAS TO retry the request until it gets a response. This algorithm is called Idle-RQ and is used for TCP for instance.

> Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
> ------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 3.1 Final
> Reporter: Sylvain Laurent
> Priority: Critical
> Fix For: 3.1.1
>
>
> We have a buggy load-balancer that sometimes forwards the request to the back-end server, and then close the connections without returning any data at all.
> This provokes a NoHttpResponseException inside commons http client 3.1, which is handled by DefaultHttpMethodRetryHandler.
> Unfortunately DefaultHttpMethodRetryHandler handles this NoHttpResponseException by asking for a retry. In our case, this is very dangerous because the request has already been sent and is being processed by the back-end server.
> I think that in the case of a NoHttpResponseException the test !method.isRequestSent() shoud be done :
> if (exception instanceof NoHttpResponseException && !method.isRequestSent()) {
> // Retry if the server dropped connection on us AND the request was not sent
> return true;
> }

[jira] Created: (HTTPCLIENT-886) Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler

2009-11-04T04:49:32Z

Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
------------------------------------------------------------------------------

Key: HTTPCLIENT-886
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
Project: HttpComponents HttpClient
Issue Type: Bug
Affects Versions: 3.1 Final
Reporter: Sylvain Laurent
Priority: Critical
Fix For: 3.1.1

We have a buggy load-balancer that sometimes forwards the request to the back-end server, and then close the connections without returning any data at all.
This provokes a NoHttpResponseException inside commons http client 3.1, which is handled by DefaultHttpMethodRetryHandler.

Unfortunately DefaultHttpMethodRetryHandler handles this NoHttpResponseException by asking for a retry. In our case, this is very dangerous because the request has already been sent and is being processed by the back-end server.

I think that in the case of a NoHttpResponseException the test !method.isRequestSent() shoud be done :

if (exception instanceof NoHttpResponseException && !method.isRequestSent()) {
// Retry if the server dropped connection on us AND the request was not sent
return true;
}

--
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-885) URLEncodedUtils fails to parse form-url-encoded entities that specify a charset

2009-11-03T14:42:33Z

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

Oleg Kalnichevski updated HTTPCLIENT-885:
-----------------------------------------

Fix Version/s: 4.1 Alpha1
4.0.1

This one appears to be a duplicate of HTTPCLIENT-880, which has been already fixed in SVN trunk. However, the use of Content-Encoding is absolutely wrong, so still more work is needed.

Oleg

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

2009-11-03T14:22:43Z

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

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

--
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-834) Transparent Content Coding support

2009-11-03T12:55:32Z

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

James Abley updated HTTPCLIENT-834:
-----------------------------------

Attachment: 834-svn-r832534-write-to.patch

Overrides HttpEntity.writeTo(OutputStream) for the new decompressing code.

[jira] Commented: (HTTPCLIENT-834) Transparent Content Coding support

2009-11-03T11:54:32Z

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

James Abley commented on HTTPCLIENT-834:
----------------------------------------

Will do. Sorry, on holiday last week and just catching up.

> Transparent Content Coding support
> ----------------------------------
>
> Key: HTTPCLIENT-834
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-834
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient
> Affects Versions: 4.0 Beta 2
> Environment: Any
> Reporter: James Abley
> Fix For: 4.1 Alpha1
>
> Attachments: 834-2009-03-17.patch, 834-docbook.patch, 834-svn-754998.patch, 834-svn-r811556.patch, 834-svn-r814881.patch, 834-svn-r815739.patch, 834-svn-r816185.patch, disable-content-coding.patch
>
>
> I would like to see HttpClient features brought up to parity with other libraries, both in Java and other languages. c.f. Python's httplib2 (not yet in the standard library, but many would like to see it in there). That library transparently handles gzip and compress content codings.
> This issue is to capture possible solutions to providing this sort of innate functionality in HttpClient, so that users aren't required to know RFC2616 intimately. The HttpClient library should do the right thing and use the network in the most efficient manner possible.

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

2009-11-02T14:48:59Z

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

Oleg Kalnichevski updated HTTPCLIENT-884:
-----------------------------------------

Priority: Minor (was: Major)
Fix Version/s: 4.1 Alpha1
4.0.1

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

2009-11-02T14:40:59Z

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

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@...

Hudson build is back to stable: HttpComponents Core #56

2009-10-31T05:20:17Z

See <http://hudson.zones.apache.org/hudson/job/HttpComponents%20Core/56/changes>

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

Hudson build is back to stable: HttpComponents Core » HttpCore NIO #56

2009-10-31T05:19:54Z

See <http://hudson.zones.apache.org/hudson/job/HttpComponents%20Core/org.apache.httpcomponents$httpcore-nio/56/changes>

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

Hudson build is unstable: HttpComponents Core #55

2009-10-31T04:32:35Z

See <http://hudson.zones.apache.org/hudson/job/HttpComponents%20Core/55/changes>

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

Hudson build is unstable: HttpComponents Core » HttpCore NIO #55

2009-10-31T04:32:31Z

See <http://hudson.zones.apache.org/hudson/job/HttpComponents%20Core/org.apache.httpcomponents$httpcore-nio/55/changes>

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

Hudson build is still unstable: HttpComponents Core #53

2009-10-31T02:30:21Z

See <http://hudson.zones.apache.org/hudson/job/HttpComponents%20Core/53/>

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

Hudson build is still unstable: HttpComponents Core » HttpCore NIO #53

2009-10-31T02:30:18Z

See <http://hudson.zones.apache.org/hudson/job/HttpComponents%20Core/org.apache.httpcomponents$httpcore-nio/53/>

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