[jira] [Commented] (HTTPCORE-595) Android Conscrypt NPE in SSL_get_shutdown shuts down IOReactor

[Gary Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922687#comment-16922687
 ] 

Gary Gregory commented on HTTPCORE-595:
---

+1 for induction in the coding horror hall of fame ;)

> Android Conscrypt NPE in SSL_get_shutdown shuts down IOReactor
> --
>
> Key: HTTPCORE-595
> URL: https://issues.apache.org/jira/browse/HTTPCORE-595
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 5.0-beta8
> Environment: Android 8.1 (Oreo)
>Reporter: Roy Hashimoto
>Priority: Major
> Fix For: 5.0-beta9
>
>
> Using HttpCore 5.0-beta8 IOReactor on Android 8.1, a TLS protocol error 
> causes the IOReactor instance to shut down.
> There is an initial {{SSLProtocolException}} from the protocol error:
> {{Read error: ssl=0x9f0ab600: Failure in SSL library, usually a protocol 
> error}}
> {{error:1416:SSL 
> routines:OPENSSL_internal:SSLV3_ALERT_CERTIFICATE_UNKNOWN 
> (external/boringssl/src/ssl/tls_record.cc:579 0x8834dc20:0x0001)}}
> This exception appears to be handled properly, but it leaves things in a 
> state so that later this {{NullPointerException}} occurs in 
> {{ConscryptEngine.isInboundDone}} which shuts down the {{IOReactor}} 
> dispatcher:
> {{2019-09-04 07:37:25.150 32414-32495/com.example.skeleton.app 
> E/MainActivity: java.lang.NullPointerException: ssl == null}}
> {{ at com.android.org.conscrypt.NativeCrypto.SSL_get_shutdown(Native Method)}}
> {{ at 
> com.android.org.conscrypt.SslWrapper.wasShutdownReceived(SslWrapper.java:483)}}
> {{ at 
> com.android.org.conscrypt.ConscryptEngine.isInboundDone(ConscryptEngine.java:590)}}
> {{ at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.updateEventMask(SSLIOSession.java:372)}}
> {{ at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.close(SSLIOSession.java:672)}}
> {{ at 
> org.apache.hc.core5.reactor.InternalDataChannel.close(InternalDataChannel.java:288)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.shutdownSession(AbstractHttp1StreamDuplexer.java:158)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onException(AbstractHttp1StreamDuplexer.java:383)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.exception(AbstractHttp1IOEventHandler.java:89)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.ServerHttp1IOEventHandler.exception(ServerHttp1IOEventHandler.java:41)}}
> {{ at 
> org.apache.hc.core5.reactor.InternalDataChannel.onException(InternalDataChannel.java:204)}}
> {{ at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:55)}}
> {{ at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:173)}}
> {{ at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:123)}}
> {{ at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:82)}}
> {{ at 
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)}}
> {{ at java.lang.Thread.run(Thread.java:764)}}
> {{2019-09-04 07:37:25.185 32414-32494/com.example.skeleton.app 
> E/MainActivity: java.lang.NullPointerException: ssl == null}}
> {{ at com.android.org.conscrypt.NativeCrypto.SSL_get_shutdown(Native Method)}}
> {{ at 
> com.android.org.conscrypt.SslWrapper.wasShutdownReceived(SslWrapper.java:483)}}
> {{ at 
> com.android.org.conscrypt.ConscryptEngine.isInboundDone(ConscryptEngine.java:590)}}
> {{ at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.updateEventMask(SSLIOSession.java:372)}}
> {{ at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.close(SSLIOSession.java:672)}}
> {{ at 
> org.apache.hc.core5.reactor.InternalDataChannel.close(InternalDataChannel.java:288)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.shutdownSession(AbstractHttp1StreamDuplexer.java:158)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onException(AbstractHttp1StreamDuplexer.java:383)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.exception(AbstractHttp1IOEventHandler.java:89)}}
> {{ at 
> org.apache.hc.core5.http.impl.nio.ServerHttp1IOEventHandler.exception(ServerHttp1IOEventHandler.java:41)}}
> {{ at 
> org.apache.hc.core5.reactor.InternalDataChannel.onException(InternalDataChannel.java:204)}}
> {{ at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:55)}}
> {{ at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:173)}}
> {{ at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:123)}}
> {{ at 
> 

[jira] [Created] (HTTPCLIENT-2014) Refactor DefaultRedirectStrategy for subclassing

[Gary Gregory (Jira)]

Gary Gregory created HTTPCLIENT-2014:


 Summary: Refactor DefaultRedirectStrategy for subclassing
 Key: HTTPCLIENT-2014
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2014
 Project: HttpComponents HttpClient
  Issue Type: Improvement
  Components: HttpClient (classic)
Reporter: Gary Gregory
Assignee: Gary Gregory


Refactor DefaultRedirectStrategy for subclassing. (#164)

- Adds the constructor DefaultRedirectStrategy(String[]) to construct a new 
instance to redirect the given HTTP methods.
- The default constructor now calls the String[] constructor.
- Reimplement the LaxRedirectStrategy default constructor to call 
DefaultRedirectStrategy(String[]).

All of this allows for new custom subclasses of DefaultRedirectStrategy to 
provide their own array of HTTP methods to redirect.




--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCLIENT-2014) Refactor DefaultRedirectStrategy for subclassing

[Gary Gregory (Jira)]

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

Gary Gregory resolved HTTPCLIENT-2014.
--
Fix Version/s: 4.5.10
   Resolution: Fixed

I am resolving for now since the code is in 4.5.x. 

For master, I do not see the need to refactor as the code is quite different.

> Refactor DefaultRedirectStrategy for subclassing
> 
>
> Key: HTTPCLIENT-2014
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2014
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.5.10
>
>
> Refactor DefaultRedirectStrategy for subclassing. (#164)
> - Adds the constructor DefaultRedirectStrategy(String[]) to construct a new 
> instance to redirect the given HTTP methods.
> - The default constructor now calls the String[] constructor.
> - Reimplement the LaxRedirectStrategy default constructor to call 
> DefaultRedirectStrategy(String[]).
> All of this allows for new custom subclasses of DefaultRedirectStrategy to 
> provide their own array of HTTP methods to redirect.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPASYNC-153) Deadlock when sending new request

[Gary Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/HTTPASYNC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914181#comment-16914181
 ] 

Gary Gregory commented on HTTPASYNC-153:


Did you mean 11.0.4?

Gary

> Deadlock when sending new request
> -
>
> Key: HTTPASYNC-153
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-153
> Project: HttpComponents HttpAsyncClient
>  Issue Type: Bug
>Affects Versions: 4.1.4
> Environment: CentOS Linux release 7.5.1804
> Java 11
>Reporter: Max Rozhkov
>Priority: Major
> Attachments: thread_print-190821-082533
>
>
> We faced a situation that async http requests are blocked at the moment they 
> are being made. This blocks work thread which make all the threads in the 
> pool blocked.
> At the same time, the thread which closes idle connections is also blocked.
> Please fix the problem. Otherwise we have to move to another http client asap.
> Typical stack traces are below:
>  
> java.lang.Thread.State: BLOCKED (on object monitor)
>  at org.apache.http.nio.reactor.ssl.SSLIOSession.close(SSLIOSession.java:605)
>  - waiting to lock <0x0011c1caa2a0> (a 
> org.apache.http.nio.reactor.ssl.SSLIOSession)
>  at 
> org.apache.http.impl.nio.NHttpConnectionBase.close(NHttpConnectionBase.java:511)
>  at 
> org.apache.http.impl.nio.conn.CPoolEntry.closeConnection(CPoolEntry.java:75)
>  at org.apache.http.impl.nio.conn.CPoolEntry.close(CPoolEntry.java:101)
>  at 
> org.apache.http.nio.pool.AbstractNIOConnPool$4.process(AbstractNIOConnPool.java:846)
>  at 
> org.apache.http.nio.pool.AbstractNIOConnPool.enumAvailable(AbstractNIOConnPool.java:775)
>  at 
> org.apache.http.nio.pool.AbstractNIOConnPool.closeIdle(AbstractNIOConnPool.java:841)
>  at 
> org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.closeIdleConnections(PoolingNHttpClientConnectionManager.java:493)
>  at 
> net.thumbtack.ssp.requester.AsyncHttpClient.lambda$monitorConnections$0(AsyncHttpClient.java:67)
>  at 
> net.thumbtack.ssp.requester.AsyncHttpClient$$Lambda$311/0x0017c2616440.run(Unknown
>  Source)
>  at 
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.1/Executors.java:515)
>  at 
> java.util.concurrent.FutureTask.runAndReset(java.base@11.0.1/FutureTask.java:305)
>  at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@11.0.1/ScheduledThreadPoolExecutor.java:305)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.1/ThreadPoolExecutor.java:1128)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.1/ThreadPoolExecutor.java:628)
>  at java.lang.Thread.run(java.base@11.0.1/Thread.java:834)
>  
> java.lang.Thread.State: WAITING (parking)
>  at jdk.internal.misc.Unsafe.park(java.base@11.0.1/Native Method)
>  - parking to wait for <0x0011310a4150> (a 
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>  at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.1/LockSupport.java:194)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.1/AbstractQueuedSynchronizer.java:885)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.1/AbstractQueuedSynchronizer.java:917)
>  at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.1/AbstractQueuedSynchronizer.java:1240)
>  at 
> java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.1/ReentrantLock.java:267)
>  at 
> org.apache.http.nio.pool.AbstractNIOConnPool.lease(AbstractNIOConnPool.java:278)
>  at 
> org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.requestConnection(PoolingNHttpClientConnectionManager.java:295)
>  at 
> org.apache.http.impl.nio.client.AbstractClientExchangeHandler.requestConnection(AbstractClientExchangeHandler.java:377)
>  at 
> org.apache.http.impl.nio.client.DefaultClientExchangeHandlerImpl.start(DefaultClientExchangeHandlerImpl.java:129)
>  at 
> org.apache.http.impl.nio.client.InternalHttpAsyncClient.execute(InternalHttpAsyncClient.java:141)
>  at 
> org.apache.http.impl.nio.client.CloseableHttpAsyncClient.execute(CloseableHttpAsyncClient.java:75)
>  at 
> org.apache.http.impl.nio.client.CloseableHttpAsyncClient.execute(CloseableHttpAsyncClient.java:108)
>  at 
> net.thumbtack.ssp.requester.AsyncHttpClient.execute(AsyncHttpClient.java:96)
>  at 
> net.thumbtack.ssp.requester.SelfHealingAsyncHttpClient.execute(SelfHealingAsyncHttpClient.java:45)
>  at 
> net.thumbtack.ssp.requester.AsyncHttpRequester.get(AsyncHttpRequester.java:125)
>  at net.thumbtack.ssp.requester.HttpRequester.get(HttpRequester.java:38)
>  at 
> net.thumbtack.ssp.impression.tracking.util.PartnerHttpNotifier.doWinNotification(PartnerHttpNotifier.java:138)
>  at 
> 

[jira] [Commented] (HTTPCLIENT-1765) SSLConnectionSocketFactory uses connectTimeout for read timeout

[Gary Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913356#comment-16913356
 ] 

Gary Gregory commented on HTTPCLIENT-1765:
--

Hi [~northfolk28],

Do you think different Javadoc comments would have helped you here? If so, 
could you propose a PR with improvements?

 

> SSLConnectionSocketFactory uses connectTimeout for read timeout
> ---
>
> Key: HTTPCLIENT-1765
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1765
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5
> Environment: Any
>Reporter: SATISH BURNWAL
>Priority: Major
>  Labels: features
>
> SSLConnectionSocketFactory uses connect timeout value for socket.soTimeout as 
> well (as per the code in SSLConnectionsocketFactory). Because of this, when 
> clients are created with such config (below), read timeout is not taking 
> effect.
> RequestConfig.Builder rb = RequestConfig.custom();
>   rb.setConnectTimeout(3000);
>   rb.setExpectContinueEnabled(true);
>   rb.setSocketTimeout(1);
>   rb.setAuthenticationEnabled(true);



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1989) NullPointerException CacheValidityPolicy#getAgeValue()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843449#comment-16843449
 ] 

Gary Gregory commented on HTTPCLIENT-1989:
--

For sure, that should be a static.

> NullPointerException CacheValidityPolicy#getAgeValue()
> --
>
> Key: HTTPCLIENT-1989
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1989
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 4.5.8
>Reporter: Eric Hubert
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> While updating from HttpClient 4.4.1 to 4.5.8 we immediately faced an issue 
> where the following NPE was thrown.
> {code:java}
> Caused by: java.lang.NullPointerException 
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getAgeValue(CacheValidityPolicy.java:236)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedReceivedAgeSecs(CacheValidityPolicy.java:253)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedInitialAgeSecs(CacheValidityPolicy.java:263)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCurrentAgeSecs(CacheValidityPolicy.java:54)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.isResponseFresh(CacheValidityPolicy.java:77)
>  
> at 
> org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.isFreshEnough(CachedResponseSuitabilityChecker.java:76)
>  
> at 
> org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.canCachedResponseBeUsed(CachedResponseSuitabilityChecker.java:147)
>  
> at 
> org.apache.http.impl.client.cache.CachingExec.handleCacheHit(CachingExec.java:291)
>  
> at 
> org.apache.http.impl.client.cache.CachingExec.execute(CachingExec.java:277) 
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) 
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) 
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) 
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>  
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>  
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108){code}
> Determining the cause wasn't that obvious, at least not to me. Therefore I 
> thought it would be a good idea to file an issue for documentation purpose. 
> Maybe someone also has a good idea how to address it.
> We use the HttpClient in conjunction with the HttpClient Caching module and 
> configured it to use the Memcached storage (MemcachedHttpCacheStorage). Our 
> memcached infrastructure systems are running all the time, also while we are 
> updating our applications using it. The memcached store serialized 
> representations of HttpCacheEntry. An HttpCacheEntry consists of a 
> HeaderGroup instance (from HttpCore).
> It looks like this class received a change (between HttpCore 4.4.1 and 4.4.2) 
> which changed the serialization, although its serialVersionUID wasn't changed:
> [https://github.com/apache/httpcomponents-core/commit/040af07704592c8acb98a5a47cbf6b90c17fe0e0#diff-5a11091c948c5a8abd9bcc6bb4f7bc0f]
> effectively resulting in an NPE while accessing its new final member EMPTY 
> (which is NULL after deserializing an object created with HttpClient 4.4.1 
> with a newer version).
> {code:java}
> private final Header[] EMPTY = new Header[] {};{code}
> I have not yet had a chance to check what would have happened, if the 
> serialVersionUID were changed, but I expect the MemcachedHttpCacheStorage to 
> create some sort of SerializationException which may have handled even before 
> in a much more graceful manner. I will test this once I find the time.
> For now we had to do a quick fallback to the old HttpClient version. Next I 
> need to look for a good solution as during rolling software upgrades we will 
> always have a time, were both HttpClient versions are in parallel usage and 
> the response caching seems to be essential (so simply turning off the cache 
> usage during the upgrade, flushing the cache and turning it on once all 
> servers are up with the new HttpClient version also does not seem to be a 
> great option).
> I'm looking forward for any ideas. Please also feel free to adjust/move this 
> ticket accordingly! It turned out not to be a bug in HttpClient Cache itself, 
> but I thought this would be a more logical place than HttpCore as it likely 
> only affects certain Cache usage scenarios.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For 

[jira] [Commented] (HTTPCLIENT-1989) NullPointerException CacheValidityPolicy#getAgeValue()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843416#comment-16843416
 ] 

Gary Gregory commented on HTTPCLIENT-1989:
--

Should we null-guard this method?

> NullPointerException CacheValidityPolicy#getAgeValue()
> --
>
> Key: HTTPCLIENT-1989
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1989
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 4.5.8
>Reporter: Eric Hubert
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> While updating from HttpClient 4.4.1 to 4.5.8 we immediately faced an issue 
> where the following NPE was thrown.
> {code:java}
> Caused by: java.lang.NullPointerException 
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getAgeValue(CacheValidityPolicy.java:236)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedReceivedAgeSecs(CacheValidityPolicy.java:253)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedInitialAgeSecs(CacheValidityPolicy.java:263)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCurrentAgeSecs(CacheValidityPolicy.java:54)
>  
> at 
> org.apache.http.impl.client.cache.CacheValidityPolicy.isResponseFresh(CacheValidityPolicy.java:77)
>  
> at 
> org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.isFreshEnough(CachedResponseSuitabilityChecker.java:76)
>  
> at 
> org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.canCachedResponseBeUsed(CachedResponseSuitabilityChecker.java:147)
>  
> at 
> org.apache.http.impl.client.cache.CachingExec.handleCacheHit(CachingExec.java:291)
>  
> at 
> org.apache.http.impl.client.cache.CachingExec.execute(CachingExec.java:277) 
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) 
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) 
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) 
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>  
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>  
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108){code}
> Determining the cause wasn't that obvious, at least not to me. Therefore I 
> thought it would be a good idea to file an issue for documentation purpose. 
> Maybe someone also has a good idea how to address it.
> We use the HttpClient in conjunction with the HttpClient Caching module and 
> configured it to use the Memcached storage (MemcachedHttpCacheStorage). Our 
> memcached infrastructure systems are running all the time, also while we are 
> updating our applications using it. The memcached store serialized 
> representations of HttpCacheEntry. An HttpCacheEntry consists of a 
> HeaderGroup instance (from HttpCore).
> It looks like this class received a change (between HttpCore 4.4.1 and 4.4.2) 
> which changed the serialization, although its serialVersionUID wasn't changed:
> [https://github.com/apache/httpcomponents-core/commit/040af07704592c8acb98a5a47cbf6b90c17fe0e0#diff-5a11091c948c5a8abd9bcc6bb4f7bc0f]
> effectively resulting in an NPE while accessing its new final member EMPTY 
> (which is NULL after deserializing an object created with HttpClient 4.4.1 
> with a newer version).
> {code:java}
> private final Header[] EMPTY = new Header[] {};{code}
> I have not yet had a chance to check what would have happened, if the 
> serialVersionUID were changed, but I expect the MemcachedHttpCacheStorage to 
> create some sort of SerializationException which may have handled even before 
> in a much more graceful manner. I will test this once I find the time.
> For now we had to do a quick fallback to the old HttpClient version. Next I 
> need to look for a good solution as during rolling software upgrades we will 
> always have a time, were both HttpClient versions are in parallel usage and 
> the response caching seems to be essential (so simply turning off the cache 
> usage during the upgrade, flushing the cache and turning it on once all 
> servers are up with the new HttpClient version also does not seem to be a 
> great option).
> I'm looking forward for any ideas. Please also feel free to adjust/move this 
> ticket accordingly! It turned out not to be a bug in HttpClient Cache itself, 
> but I thought this would be a more logical place than HttpCore as it likely 
> only affects certain Cache usage scenarios.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For 

[jira] [Commented] (HTTPCLIENT-1985) Single version for httpcore, httpclient, httpasyncclient

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821894#comment-16821894
 ] 

Gary Gregory commented on HTTPCLIENT-1985:
--

Like me :)

Gary

> Single version for httpcore, httpclient, httpasyncclient
> 
>
> Key: HTTPCLIENT-1985
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1985
> Project: HttpComponents HttpClient
>  Issue Type: Wish
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 5.0 Beta4
>Reporter: Sergey Chernov
>Priority: Major
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Probably this topic was discussed in the mailing list, but I could not find 
> it.
> Anyway, the problem is that there is at least three repos with 3 groups of 
> artifacts: core, client, asyncclient, each group has its own version.
> The site instruction says: just import 
> "org.apache.httpcomponents:httpclient:${httpclient.version}" and be happy 
> (simplified).
> But in fact in a complicated project with big count of dependencies including 
> dozens of artifacts, there can easily be a jar hell with incompatible 
> versions of artifacts.
> If you are good with maven, you understand the power of dependencyManagement 
> or even have a spring-boot-dependencies parent 
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-dependencies/pom.xml
>  for the project.
> Which version of httpasyncclient should you choose if you already have 
> httpclient of version A and httpcore of version B (that can vary in different 
> modules of the multi-module maven project)?
> You have to find a compatible version with core or update everything. Again, 
> you have to understand all these details or just voodoo unless success (that 
> can break application runtime of course).
> It's hard to imagine how many applications and developers suffered because of 
> it.
> I suppose the main reason for this decision was not to release the artifact 
> that is not updated. But it brings more evil, than good.
> Whatever, I hoped that new generation of the http client will unite all three 
> repos to one with single version. Like kotlin, spring-framework, spring-boot 
> or netty. But it's not.
> Why? It's not yet too late before the client 5 is released.
> I bet spring-boot developers will support this idea :D
> Sorry, if it was discussed in the mailing lists or if I should post it there. 
> Please let me know what you think.
> Thanks in any case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1978) Unicode header values are converted into mojibake

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806157#comment-16806157
 ] 

Gary Gregory commented on HTTPCLIENT-1978:
--

I think we need to be careful and consider:
 - Should we break existing apps with an IllegalArgumentException? This could 
seriously sink existing apps.
 - Should we make the change "complex" by allowing call sites to plug in a 
header policy:
 -- truncate value on first illegal char,
 -- replace illegal chars,
 -- IllegalArgumentException?
 - Should we make the change "simple" by replacing chars > 255 and chars < 32 
with '?'.

At the very least what I think we should do is change the current behavior by 
replacing chars > 255 and chars < 32 with '?'

WDYT?

> Unicode header values are converted into mojibake
> -
>
> Key: HTTPCLIENT-1978
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1978
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7, 5.0 Beta3
>Reporter: Ryan Schmitt
>Priority: Major
>
> Unicode handling is badly broken, as the below examples show:
> {{httpget.addHeader("X-I-Expect-This-Header", "Федор Достоевский")}} => 
> {{X-I-Expect-This-Header: $54>@ >AB>52A:89}}
> {{httpget.addHeader("X-I-Expect-This-Header", "宮本茂")}} => 
> {{X-I-Expect-This-Header: �,}}
> {{httpget.addHeader("X-I-Expect-This-Header", "Ἀριστοτέλης")}} => 
> {{X-I-Expect-This-Header:���Ŀĭ���}}
> The root cause is 
> [here|https://github.com/apache/httpcomponents-core/blob/589fe21a0bd3481431f08d296fff1e323a8f497d/httpcore5/src/main/java/org/apache/hc/core5/util/ByteArrayBuffer.java#L138-L140]:
> {code:java}
> for (int i1 = off, i2 = oldlen; i2 < newlen; i1++, i2++) {
> this.array[i2] = (byte) b[i1];
> }
> {code}
> In this code, {{b}} is of type {{char[]}} and {{array}} is of type 
> {{byte[]}}. According to [JLS § 
> 5.1.3|https://docs.oracle.com/javase/specs/jls/se11/html/jls-5.html#jls-5.1.3]
>  ("Narrowing Primitive Conversion"), "[a] narrowing conversion of a {{char}} 
> to an integral type T likewise simply discards all but the _n_ lowest order 
> bits, where _n_ is the number of bits used to represent type T."
> There are a few ways we could fix this, and any of them would be better than 
> what we are doing now. The two I'll propose for consideration are:
> # Just write UTF-8 to the wire; non-ASCII characters should be tolerated as 
> {{obs-text}}
> # Replace non-ASCII characters with an empty string, space, or question mark
> See also: https://issues.apache.org/jira/browse/HTTPCLIENT-1974



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Comment Edited] (HTTPCLIENT-1978) Unicode header values are converted into mojibake

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805562#comment-16805562
 ] 

Gary Gregory edited comment on HTTPCLIENT-1978 at 3/30/19 1:43 AM:
---

* What about chars < 31?
 * A question mark for a substituted char seems OK.


was (Author: garydgregory):
What about chars < 31?

> Unicode header values are converted into mojibake
> -
>
> Key: HTTPCLIENT-1978
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1978
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7, 5.0 Beta3
>Reporter: Ryan Schmitt
>Priority: Major
>
> Unicode handling is badly broken, as the below examples show:
> {{httpget.addHeader("X-I-Expect-This-Header", "Федор Достоевский")}} => 
> {{X-I-Expect-This-Header: $54>@ >AB>52A:89}}
> {{httpget.addHeader("X-I-Expect-This-Header", "宮本茂")}} => 
> {{X-I-Expect-This-Header: �,}}
> {{httpget.addHeader("X-I-Expect-This-Header", "Ἀριστοτέλης")}} => 
> {{X-I-Expect-This-Header:���Ŀĭ���}}
> The root cause is 
> [here|https://github.com/apache/httpcomponents-core/blob/589fe21a0bd3481431f08d296fff1e323a8f497d/httpcore5/src/main/java/org/apache/hc/core5/util/ByteArrayBuffer.java#L138-L140]:
> {code:java}
> for (int i1 = off, i2 = oldlen; i2 < newlen; i1++, i2++) {
> this.array[i2] = (byte) b[i1];
> }
> {code}
> In this code, {{b}} is of type {{char[]}} and {{array}} is of type 
> {{byte[]}}. According to [JLS § 
> 5.1.3|https://docs.oracle.com/javase/specs/jls/se11/html/jls-5.html#jls-5.1.3]
>  ("Narrowing Primitive Conversion"), "[a] narrowing conversion of a {{char}} 
> to an integral type T likewise simply discards all but the _n_ lowest order 
> bits, where _n_ is the number of bits used to represent type T."
> There are a few ways we could fix this, and any of them would be better than 
> what we are doing now. The two I'll propose for consideration are:
> # Just write UTF-8 to the wire; non-ASCII characters should be tolerated as 
> {{obs-text}}
> # Replace non-ASCII characters with an empty string, space, or question mark
> See also: https://issues.apache.org/jira/browse/HTTPCLIENT-1974



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1978) Unicode header values are converted into mojibake

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805562#comment-16805562
 ] 

Gary Gregory commented on HTTPCLIENT-1978:
--

What about chars < 31?

> Unicode header values are converted into mojibake
> -
>
> Key: HTTPCLIENT-1978
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1978
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7, 5.0 Beta3
>Reporter: Ryan Schmitt
>Priority: Major
>
> Unicode handling is badly broken, as the below examples show:
> {{httpget.addHeader("X-I-Expect-This-Header", "Федор Достоевский")}} => 
> {{X-I-Expect-This-Header: $54>@ >AB>52A:89}}
> {{httpget.addHeader("X-I-Expect-This-Header", "宮本茂")}} => 
> {{X-I-Expect-This-Header: �,}}
> {{httpget.addHeader("X-I-Expect-This-Header", "Ἀριστοτέλης")}} => 
> {{X-I-Expect-This-Header:���Ŀĭ���}}
> The root cause is 
> [here|https://github.com/apache/httpcomponents-core/blob/589fe21a0bd3481431f08d296fff1e323a8f497d/httpcore5/src/main/java/org/apache/hc/core5/util/ByteArrayBuffer.java#L138-L140]:
> {code:java}
> for (int i1 = off, i2 = oldlen; i2 < newlen; i1++, i2++) {
> this.array[i2] = (byte) b[i1];
> }
> {code}
> In this code, {{b}} is of type {{char[]}} and {{array}} is of type 
> {{byte[]}}. According to [JLS § 
> 5.1.3|https://docs.oracle.com/javase/specs/jls/se11/html/jls-5.html#jls-5.1.3]
>  ("Narrowing Primitive Conversion"), "[a] narrowing conversion of a {{char}} 
> to an integral type T likewise simply discards all but the _n_ lowest order 
> bits, where _n_ is the number of bits used to represent type T."
> There are a few ways we could fix this, and any of them would be better than 
> what we are doing now. The two I'll propose for consideration are:
> # Just write UTF-8 to the wire; non-ASCII characters should be tolerated as 
> {{obs-text}}
> # Replace non-ASCII characters with an empty string, space, or question mark
> See also: https://issues.apache.org/jira/browse/HTTPCLIENT-1974



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1974) CRLF injection vulnerability in setting/adding HTTP headers

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCLIENT-1974.


Per [~olegk]'s request, I am closing this issue. Anyone can create a JIRA for 
one of or all of:

- the API is misnamed because it behaves more like "append all this stuff" 
instead of "append one header" like the API name and Javadoc says, 
- the API is buggy because it does not sanitize its input, 
- the API is buggy because it does not throw an exception on invalid input. We 
cannot simply rename the API in 4.x, so if no code changes then we should ask 
ourselves if this surprising behavior should be documented.

> CRLF injection vulnerability in setting/adding HTTP headers
> ---
>
> Key: HTTPCLIENT-1974
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1974
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7
>Reporter: Filip Ochnik
>Priority: Major
>
> Hello,
>  
> Note: This vulnerability has already been reported using a private channel. 
> Unfortunately, it was deemed as non-issue by maintainers. I'm posting it here 
> for public visibility.
>  
> *Summary*
> HttpClient in versions 4.5.7 and below is vulnerable to CRLF injection when 
> adding or setting headers on an HTTP request. Attacker who can control the 
> value of any header in a request created using HttpClient could exploit this 
> vulnerability to add arbitrary headers and attack internal services, like a 
> webserver, Redis, memcached, etc.
>  
> *Details*
> The current version of HttpClient does not properly filter unicode values, 
> resulting in the sequence '{color:#00}\u560d\u560a{color}' being 
> converted to `\r\n` and causing unintended behavior. When the value (or part 
> of the value) of any header set when constructing an HTTP request using 
> HttpClient is controlled by an attacker, it allows them to insert arbitrary 
> content to the new line of the HTTP header.
>  
> *Proof of concept*
> Consider this piece of code, where variable "attackerControlledValue" 
> simulates an attacker-controlled input.
>  
> {code:java}
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> public class Main {
>    public final static void main(String[] args) throws Exception {
>        CloseableHttpClient httpclient = HttpClients.createDefault();
>        String attackerControlledValue = "1\u560d\u560aX-But-Not-This-One: oh 
> no!";
>        try {
>            HttpGet httpget = new HttpGet("http://127.0.0.1:8080/;);
>            httpget.addHeader("X-I-Expect-This-Header", 
> attackerControlledValue);
>            httpclient.execute(httpget);
>        } finally {
>            httpclient.close();
>        }
>    }
> }{code}
>  
>  
> We set up a netcat listener on port 8080 and run this code:
>  
> {code:java}
> $ nc -l 8080
> GET / HTTP/1.1
> X-I-Expect-This-Header: 1
> X-But-Not-This-One: oh no!
> Host: 127.0.0.1:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.5.7 (Java/1.8.0_172)
> Accept-Encoding: gzip,deflate
> {code}
>  
> We can see in the netcat output that the header 
> "{color:#00}X-But-Not-This-One{color}" is present in the request, which 
> means the injection succeeded.
>  
> *Attack scenarios*
>  * By adding arbitrary HTTP headers it's possible to bypass authentication of 
> some simple web services
>  * Several simple services that communicate over HTTP (Redis, memcached) can 
> be exploited by injecting valid commands
>  
> *Related vulnerabilities*
> Here are some related CRLF injection vulnerabilities in other software:
>  * CVE-2016-5699 in Python’s stdlib 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-5699]
>  * CVE-2017-6508 in wget [https://nvd.nist.gov/vuln/detail/CVE-2017-6508]
>  * CVE-2016-4993 in Undertow web server 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-4993]
>  * CVE-2019-9740 in Python's stdlib again 
> [https://nvd.nist.gov/vuln/detail/CVE-2019-9740]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Reopened] (HTTPCLIENT-1974) CRLF injection vulnerability in setting/adding HTTP headers

[Gary Gregory (JIRA)]

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

Gary Gregory reopened HTTPCLIENT-1974:
--

I am re-opening this issue to try to get to one of three outcomes:

I agree that this does not fit the traditional description of a vulnerability. 
This sure feels to me like an edge case where either (1) the API is misnamed 
because it behaves more like "append all this stuff" instead of "append one 
header" like the API name and Javadoc says, or (2) the API is buggy because it 
does not sanitize its input, or (3) the API is buggy because it does not throw 
an exception on invalid input. We cannot simply rename the API in 4.x, so if no 
code changes then we should ask ourselves if this surprising behavior should be 
documented.

Thoughts?

> CRLF injection vulnerability in setting/adding HTTP headers
> ---
>
> Key: HTTPCLIENT-1974
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1974
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7
>Reporter: Filip Ochnik
>Priority: Major
>
> Hello,
>  
> Note: This vulnerability has already been reported using a private channel. 
> Unfortunately, it was deemed as non-issue by maintainers. I'm posting it here 
> for public visibility.
>  
> *Summary*
> HttpClient in versions 4.5.7 and below is vulnerable to CRLF injection when 
> adding or setting headers on an HTTP request. Attacker who can control the 
> value of any header in a request created using HttpClient could exploit this 
> vulnerability to add arbitrary headers and attack internal services, like a 
> webserver, Redis, memcached, etc.
>  
> *Details*
> The current version of HttpClient does not properly filter unicode values, 
> resulting in the sequence '{color:#00}\u560d\u560a{color}' being 
> converted to `\r\n` and causing unintended behavior. When the value (or part 
> of the value) of any header set when constructing an HTTP request using 
> HttpClient is controlled by an attacker, it allows them to insert arbitrary 
> content to the new line of the HTTP header.
>  
> *Proof of concept*
> Consider this piece of code, where variable "attackerControlledValue" 
> simulates an attacker-controlled input.
>  
> {code:java}
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> public class Main {
>    public final static void main(String[] args) throws Exception {
>        CloseableHttpClient httpclient = HttpClients.createDefault();
>        String attackerControlledValue = "1\u560d\u560aX-But-Not-This-One: oh 
> no!";
>        try {
>            HttpGet httpget = new HttpGet("http://127.0.0.1:8080/;);
>            httpget.addHeader("X-I-Expect-This-Header", 
> attackerControlledValue);
>            httpclient.execute(httpget);
>        } finally {
>            httpclient.close();
>        }
>    }
> }{code}
>  
>  
> We set up a netcat listener on port 8080 and run this code:
>  
> {code:java}
> $ nc -l 8080
> GET / HTTP/1.1
> X-I-Expect-This-Header: 1
> X-But-Not-This-One: oh no!
> Host: 127.0.0.1:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.5.7 (Java/1.8.0_172)
> Accept-Encoding: gzip,deflate
> {code}
>  
> We can see in the netcat output that the header 
> "{color:#00}X-But-Not-This-One{color}" is present in the request, which 
> means the injection succeeded.
>  
> *Attack scenarios*
>  * By adding arbitrary HTTP headers it's possible to bypass authentication of 
> some simple web services
>  * Several simple services that communicate over HTTP (Redis, memcached) can 
> be exploited by injecting valid commands
>  
> *Related vulnerabilities*
> Here are some related CRLF injection vulnerabilities in other software:
>  * CVE-2016-5699 in Python’s stdlib 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-5699]
>  * CVE-2017-6508 in wget [https://nvd.nist.gov/vuln/detail/CVE-2017-6508]
>  * CVE-2016-4993 in Undertow web server 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-4993]
>  * CVE-2019-9740 in Python's stdlib again 
> [https://nvd.nist.gov/vuln/detail/CVE-2019-9740]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1974) CRLF injection vulnerability in setting/adding HTTP headers

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798142#comment-16798142
 ] 

Gary Gregory commented on HTTPCLIENT-1974:
--

What is "different" here is that we have APIs that advertise working with a 
single header when in fact you can feed it garbage. If we define the current 
APIs as "correct", then the APIs are misnamed IMO. For example 
{{org.apache.http.client.methods.RequestBuilder.addHeader(String, String)}} is 
really {{addTextToHeaderArea()}}.

> CRLF injection vulnerability in setting/adding HTTP headers
> ---
>
> Key: HTTPCLIENT-1974
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1974
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7
>Reporter: Filip Ochnik
>Priority: Major
>
> Hello,
>  
> Note: This vulnerability has already been reported using a private channel. 
> Unfortunately, it was deemed as non-issue by maintainers. I'm posting it here 
> for public visibility.
>  
> *Summary*
> HttpClient in versions 4.5.7 and below is vulnerable to CRLF injection when 
> adding or setting headers on an HTTP request. Attacker who can control the 
> value of any header in a request created using HttpClient could exploit this 
> vulnerability to add arbitrary headers and attack internal services, like a 
> webserver, Redis, memcached, etc.
>  
> *Details*
> The current version of HttpClient does not properly filter unicode values, 
> resulting in the sequence '{color:#00}\u560d\u560a{color}' being 
> converted to `\r\n` and causing unintended behavior. When the value (or part 
> of the value) of any header set when constructing an HTTP request using 
> HttpClient is controlled by an attacker, it allows them to insert arbitrary 
> content to the new line of the HTTP header.
>  
> *Proof of concept*
> Consider this piece of code, where variable "attackerControlledValue" 
> simulates an attacker-controlled input.
>  
> {code:java}
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> public class Main {
>    public final static void main(String[] args) throws Exception {
>        CloseableHttpClient httpclient = HttpClients.createDefault();
>        String attackerControlledValue = "1\u560d\u560aX-But-Not-This-One: oh 
> no!";
>        try {
>            HttpGet httpget = new HttpGet("http://127.0.0.1:8080/;);
>            httpget.addHeader("X-I-Expect-This-Header", 
> attackerControlledValue);
>            httpclient.execute(httpget);
>        } finally {
>            httpclient.close();
>        }
>    }
> }{code}
>  
>  
> We set up a netcat listener on port 8080 and run this code:
>  
> {code:java}
> $ nc -l 8080
> GET / HTTP/1.1
> X-I-Expect-This-Header: 1
> X-But-Not-This-One: oh no!
> Host: 127.0.0.1:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.5.7 (Java/1.8.0_172)
> Accept-Encoding: gzip,deflate
> {code}
>  
> We can see in the netcat output that the header 
> "{color:#00}X-But-Not-This-One{color}" is present in the request, which 
> means the injection succeeded.
>  
> *Attack scenarios*
>  * By adding arbitrary HTTP headers it's possible to bypass authentication of 
> some simple web services
>  * Several simple services that communicate over HTTP (Redis, memcached) can 
> be exploited by injecting valid commands
>  
> *Related vulnerabilities*
> Here are some related CRLF injection vulnerabilities in other software:
>  * CVE-2016-5699 in Python’s stdlib 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-5699]
>  * CVE-2017-6508 in wget [https://nvd.nist.gov/vuln/detail/CVE-2017-6508]
>  * CVE-2016-4993 in Undertow web server 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-4993]
>  * CVE-2019-9740 in Python's stdlib again 
> [https://nvd.nist.gov/vuln/detail/CVE-2019-9740]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1974) CRLF injection vulnerability in setting/adding HTTP headers

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797463#comment-16797463
 ] 

Gary Gregory commented on HTTPCLIENT-1974:
--

Hm, yeah, good point [~rschmitt], in that case then, calling {{addHeader()}} is 
similar to the stored procedure case. We are saying: Fill the next HTTP header 
slot with this name and value. But what can happen is that you end up with more 
than one resulting header. Quite surprising indeed and not what the API 
advertises.

> CRLF injection vulnerability in setting/adding HTTP headers
> ---
>
> Key: HTTPCLIENT-1974
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1974
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7
>Reporter: Filip Ochnik
>Priority: Major
>
> Hello,
>  
> Note: This vulnerability has already been reported using a private channel. 
> Unfortunately, it was deemed as non-issue by maintainers. I'm posting it here 
> for public visibility.
>  
> *Summary*
> HttpClient in versions 4.5.7 and below is vulnerable to CRLF injection when 
> adding or setting headers on an HTTP request. Attacker who can control the 
> value of any header in a request created using HttpClient could exploit this 
> vulnerability to add arbitrary headers and attack internal services, like a 
> webserver, Redis, memcached, etc.
>  
> *Details*
> The current version of HttpClient does not properly filter unicode values, 
> resulting in the sequence '{color:#00}\u560d\u560a{color}' being 
> converted to `\r\n` and causing unintended behavior. When the value (or part 
> of the value) of any header set when constructing an HTTP request using 
> HttpClient is controlled by an attacker, it allows them to insert arbitrary 
> content to the new line of the HTTP header.
>  
> *Proof of concept*
> Consider this piece of code, where variable "attackerControlledValue" 
> simulates an attacker-controlled input.
>  
> {code:java}
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> public class Main {
>    public final static void main(String[] args) throws Exception {
>        CloseableHttpClient httpclient = HttpClients.createDefault();
>        String attackerControlledValue = "1\u560d\u560aX-But-Not-This-One: oh 
> no!";
>        try {
>            HttpGet httpget = new HttpGet("http://127.0.0.1:8080/;);
>            httpget.addHeader("X-I-Expect-This-Header", 
> attackerControlledValue);
>            httpclient.execute(httpget);
>        } finally {
>            httpclient.close();
>        }
>    }
> }{code}
>  
>  
> We set up a netcat listener on port 8080 and run this code:
>  
> {code:java}
> $ nc -l 8080
> GET / HTTP/1.1
> X-I-Expect-This-Header: 1
> X-But-Not-This-One: oh no!
> Host: 127.0.0.1:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.5.7 (Java/1.8.0_172)
> Accept-Encoding: gzip,deflate
> {code}
>  
> We can see in the netcat output that the header 
> "{color:#00}X-But-Not-This-One{color}" is present in the request, which 
> means the injection succeeded.
>  
> *Attack scenarios*
>  * By adding arbitrary HTTP headers it's possible to bypass authentication of 
> some simple web services
>  * Several simple services that communicate over HTTP (Redis, memcached) can 
> be exploited by injecting valid commands
>  
> *Related vulnerabilities*
> Here are some related CRLF injection vulnerabilities in other software:
>  * CVE-2016-5699 in Python’s stdlib 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-5699]
>  * CVE-2017-6508 in wget [https://nvd.nist.gov/vuln/detail/CVE-2017-6508]
>  * CVE-2016-4993 in Undertow web server 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-4993]
>  * CVE-2019-9740 in Python's stdlib again 
> [https://nvd.nist.gov/vuln/detail/CVE-2019-9740]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1974) CRLF injection vulnerability in setting/adding HTTP headers

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797450#comment-16797450
 ] 

Gary Gregory commented on HTTPCLIENT-1974:
--

Hi All:

In the case of databases, an app that allows SQL injections is poorly coded. 
Even if an app does not validate input, using stored procedures can avoid SQL 
injection attacks. Drawing the parallel to HttpClient: If you do not validate 
input, you are open to HTTP header injection. So solution one is to validate 
your input before building a request just like you should validate input before 
building a SQL string. 

For a second solution... well, we do not have the equivalent to store 
procedures. Maybe the solution today is to point out that you can implement 
your own headers (using HttpCore interfaces) that perform validation. What 
would the validation rules be? No EOLs in header names and values? If we had 
such a header implementation (as opposed to telling people to do it 
themselves), why would you not using them by default? Performance perhaps?

In any case, this topic seems to come up again and again. It seems we should at 
least document where we stand.

> CRLF injection vulnerability in setting/adding HTTP headers
> ---
>
> Key: HTTPCLIENT-1974
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1974
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.7
>Reporter: Filip Ochnik
>Priority: Major
>
> Hello,
>  
> Note: This vulnerability has already been reported using a private channel. 
> Unfortunately, it was deemed as non-issue by maintainers. I'm posting it here 
> for public visibility.
>  
> *Summary*
> HttpClient in versions 4.5.7 and below is vulnerable to CRLF injection when 
> adding or setting headers on an HTTP request. Attacker who can control the 
> value of any header in a request created using HttpClient could exploit this 
> vulnerability to add arbitrary headers and attack internal services, like a 
> webserver, Redis, memcached, etc.
>  
> *Details*
> The current version of HttpClient does not properly filter unicode values, 
> resulting in the sequence '{color:#00}\u560d\u560a{color}' being 
> converted to `\r\n` and causing unintended behavior. When the value (or part 
> of the value) of any header set when constructing an HTTP request using 
> HttpClient is controlled by an attacker, it allows them to insert arbitrary 
> content to the new line of the HTTP header.
>  
> *Proof of concept*
> Consider this piece of code, where variable "attackerControlledValue" 
> simulates an attacker-controlled input.
>  
> {code:java}
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> public class Main {
>    public final static void main(String[] args) throws Exception {
>        CloseableHttpClient httpclient = HttpClients.createDefault();
>        String attackerControlledValue = "1\u560d\u560aX-But-Not-This-One: oh 
> no!";
>        try {
>            HttpGet httpget = new HttpGet("http://127.0.0.1:8080/;);
>            httpget.addHeader("X-I-Expect-This-Header", 
> attackerControlledValue);
>            httpclient.execute(httpget);
>        } finally {
>            httpclient.close();
>        }
>    }
> }{code}
>  
>  
> We set up a netcat listener on port 8080 and run this code:
>  
> {code:java}
> $ nc -l 8080
> GET / HTTP/1.1
> X-I-Expect-This-Header: 1
> X-But-Not-This-One: oh no!
> Host: 127.0.0.1:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.5.7 (Java/1.8.0_172)
> Accept-Encoding: gzip,deflate
> {code}
>  
> We can see in the netcat output that the header 
> "{color:#00}X-But-Not-This-One{color}" is present in the request, which 
> means the injection succeeded.
>  
> *Attack scenarios*
>  * By adding arbitrary HTTP headers it's possible to bypass authentication of 
> some simple web services
>  * Several simple services that communicate over HTTP (Redis, memcached) can 
> be exploited by injecting valid commands
>  
> *Related vulnerabilities*
> Here are some related CRLF injection vulnerabilities in other software:
>  * CVE-2016-5699 in Python’s stdlib 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-5699]
>  * CVE-2017-6508 in wget [https://nvd.nist.gov/vuln/detail/CVE-2017-6508]
>  * CVE-2016-4993 in Undertow web server 
> [https://nvd.nist.gov/vuln/detail/CVE-2016-4993]
>  * CVE-2019-9740 in Python's stdlib again 
> [https://nvd.nist.gov/vuln/detail/CVE-2019-9740]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: 

[jira] [Created] (HTTPCORE-572) Move examples to the src/test folders for each module

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-572:
-

 Summary: Move examples to the src/test folders for each module
 Key: HTTPCORE-572
 URL: https://issues.apache.org/jira/browse/HTTPCORE-572
 Project: HttpComponents HttpCore
  Issue Type: Improvement
  Components: Examples
Reporter: Gary Gregory
Assignee: Gary Gregory


I think it would be better if our examples lived in a .examples. package under 
the src/test folder. The advantages are:
 
- Examples would always be compiled by Maven and IDEs
- Examples would end up living in the test jar, which would be handy for 
testing certain use-cases. In my case, testing using our static file server and 
proxy.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16763581#comment-16763581
 ] 

Gary Gregory commented on HTTPCORE-570:
---

Thanks for merging [~olegk]. Now what remains are the compiler warnings due to 
the generics being unused. I could not get those to compile.

> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Reopened] (HTTPCORE-569) Create new value in org.apache.hc.core5.http.protocol.UriPatternType to lookup without an exact match override

[Gary Gregory (JIRA)]

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

Gary Gregory reopened HTTPCORE-569:
---

I am re-opening this because I need a new matcher class. The want to enforce 
the order and the current implementation also is clever WRT finding a "best 
match".

> Create new value in org.apache.hc.core5.http.protocol.UriPatternType to 
> lookup without an exact match override
> --
>
> Key: HTTPCORE-569
> URL: https://issues.apache.org/jira/browse/HTTPCORE-569
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta7
>
>
> Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
> lookup values without an exact match override: This allows path matches 
> _without_ having an exact match override the order in which the patterns are 
> defined (which is the current behavior.)
> This is a request from some of my users at work, they just want to a list of 
> URI patterns in a specific order which is observed no matter what. Very handy 
> for testing.
> The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
> be passed in.
> I created branch {{HTTPCORE-569}} with a proposal.
> You use this by calling 
> {{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762891#comment-16762891
 ] 

Gary Gregory commented on HTTPCORE-570:
---

I am happy with the branch now. Feel free to merge, otherwise I'll follow 
https://makandracards.com/makandra/527-squash-several-git-commits-into-a-single-commit

Thank you,

Gary

> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-569) Create new value in org.apache.hc.core5.http.protocol.UriPatternType to lookup without an exact match override

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762830#comment-16762830
 ] 

Gary Gregory commented on HTTPCORE-569:
---

Dang, I thought I'd done that, sorry about that.

> Create new value in org.apache.hc.core5.http.protocol.UriPatternType to 
> lookup without an exact match override
> --
>
> Key: HTTPCORE-569
> URL: https://issues.apache.org/jira/browse/HTTPCORE-569
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta7
>
>
> Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
> lookup values without an exact match override: This allows path matches 
> _without_ having an exact match override the order in which the patterns are 
> defined (which is the current behavior.)
> This is a request from some of my users at work, they just want to a list of 
> URI patterns in a specific order which is observed no matter what. Very handy 
> for testing.
> The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
> be passed in.
> I created branch {{HTTPCORE-569}} with a proposal.
> You use this by calling 
> {{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCORE-569) Create new value in org.apache.hc.core5.http.protocol.UriPatternType to lookup without an exact match override

[Gary Gregory (JIRA)]

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

Gary Gregory resolved HTTPCORE-569.
---
   Resolution: Fixed
Fix Version/s: 5.0-beta7

Merged.

> Create new value in org.apache.hc.core5.http.protocol.UriPatternType to 
> lookup without an exact match override
> --
>
> Key: HTTPCORE-569
> URL: https://issues.apache.org/jira/browse/HTTPCORE-569
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta7
>
>
> Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
> lookup values without an exact match override: This allows path matches 
> _without_ having an exact match override the order in which the patterns are 
> defined (which is the current behavior.)
> This is a request from some of my users at work, they just want to a list of 
> URI patterns in a specific order which is observed no matter what. Very handy 
> for testing.
> The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
> be passed in.
> I created branch {{HTTPCORE-569}} with a proposal.
> You use this by calling 
> {{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Comment Edited] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762721#comment-16762721
 ] 

Gary Gregory edited comment on HTTPCORE-570 at 2/7/19 2:40 PM:
---

Ok, cool. Please take a look at the HEAD of the HTTPCORE-570 branch. The 
changes are MUCH less.

Tangent: I'd like to make the setters fluent.


was (Author: garydgregory):
Ok, cool. Please take a look at the HEAD of the HTTPCORE-570 branch. The 
changes are MUCH less.

> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762721#comment-16762721
 ] 

Gary Gregory commented on HTTPCORE-570:
---

Ok, cool. Please take a look at the HEAD of the HTTPCORE-570 branch. The 
changes are MUCH less.

> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762652#comment-16762652
 ] 

Gary Gregory commented on HTTPCORE-570:
---

Hi [~olegk],

Thank you for taking the time to review.

What I'd like to do, in this specific case, is plugin custom suppliers to 
{{org.apache.hc.core5.http.protocol.RequestHandlerRegistry.RequestHandlerRegistry(String,
 Supplier>)}} without having to write my own 
{{AsyncServerBootstrap}} since my server already uses {{AsyncServerBootstrap}} 
quite nicely. 

While we have 
{{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}
 which nicely encapsulates our built-in lookups, the bootstrap class does not 
let you plug in your own, and that's what I need.

Perhaps the KISS would be to add a single API to {{AsyncServerBootstrap}} 
called {{setRequestHandlerRegistryLookupSupplier(Supplier>)}} 
or more just {{setRequestHandlerRegistryLookup(LookupRegistry)}}?

There is also something wrong with generic types I'm pretty sure. See my email 
on the dev ML.

Thank you,
Gary

> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Comment Edited] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762652#comment-16762652
 ] 

Gary Gregory edited comment on HTTPCORE-570 at 2/7/19 1:18 PM:
---

Hi [~olegk],

Thank you for taking the time to review.

What I'd like to do, in this specific case, is plugin custom suppliers to 
{{org.apache.hc.core5.http.protocol.RequestHandlerRegistry.RequestHandlerRegistry(String,
 Supplier>)}} without having to write my own 
{{AsyncServerBootstrap}} since my server already uses {{AsyncServerBootstrap}} 
quite nicely.

While we have 
{{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}
 which nicely encapsulates our built-in lookups, the bootstrap class does not 
let you plug in your own, and that's what I need.

Perhaps the KISS would be to add a single API to {{AsyncServerBootstrap}} 
called {{setRequestHandlerRegistryLookupSupplier(Supplier>)}} 
or just {{setRequestHandlerRegistryLookup(LookupRegistry)}}?

There is also something wrong with generic types I'm pretty sure. See my email 
on the dev ML.

Thank you,
 Gary


was (Author: garydgregory):
Hi [~olegk],

Thank you for taking the time to review.

What I'd like to do, in this specific case, is plugin custom suppliers to 
{{org.apache.hc.core5.http.protocol.RequestHandlerRegistry.RequestHandlerRegistry(String,
 Supplier>)}} without having to write my own 
{{AsyncServerBootstrap}} since my server already uses {{AsyncServerBootstrap}} 
quite nicely. 

While we have 
{{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}
 which nicely encapsulates our built-in lookups, the bootstrap class does not 
let you plug in your own, and that's what I need.

Perhaps the KISS would be to add a single API to {{AsyncServerBootstrap}} 
called {{setRequestHandlerRegistryLookupSupplier(Supplier>)}} 
or more just {{setRequestHandlerRegistryLookup(LookupRegistry)}}?

There is also something wrong with generic types I'm pretty sure. See my email 
on the dev ML.

Thank you,
Gary

> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762510#comment-16762510
 ] 

Gary Gregory commented on HTTPCORE-570:
---

The changes can be minimized by making instance variables protected instead of 
adding getters. WDYT?

Gary 

> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCORE-570:
--
Description: 
Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
implementation into protected methods.

Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
{{create()}} method but you cannot get to instance variables as these are 
private.

The goal is to make creating instances of {{HttpAsyncServer}} simpler by adding 
getters and refactoring create() implementations into protected methods such 
that subclasses can more simply create custom instances.

That does not seem controversial to me so I am not sure a feature branch is 
needed but I'll create one anyway: {{HTTPCORE-570}}

  was:
Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
implementation into protected methods.

Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
{{create()}} method but you cannot get to instance variables as these are 
private.

The goal is to make creating instances of {{HttpAsyncServer}} simpler by adding 
getters and refactoring create() implementations into protected methods such 
that subclasses can more simply create custom instances.

That does not seem controversial to me so I am not sure a feature branch is 
needed but I'll create one anyway.


> Add getters to AsyncServerBootstrap and refactor create() impl into protected 
> methods
> -
>
> Key: HTTPCORE-570
> URL: https://issues.apache.org/jira/browse/HTTPCORE-570
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
> implementation into protected methods.
> Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
> {{create()}} method but you cannot get to instance variables as these are 
> private.
> The goal is to make creating instances of {{HttpAsyncServer}} simpler by 
> adding getters and refactoring create() implementations into protected 
> methods such that subclasses can more simply create custom instances.
> That does not seem controversial to me so I am not sure a feature branch is 
> needed but I'll create one anyway: {{HTTPCORE-570}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCORE-569) Create new value in org.apache.hc.core5.http.protocol.UriPatternType to lookup without an exact match override

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCORE-569:
--
Description: 
Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
lookup values without an exact match override: This allows path matches 
_without_ having an exact match override the order in which the patterns are 
defined (which is the current behavior.)

This is a request from some of my users at work, they just want to a list of 
URI patterns in a specific order which is observed no matter what. Very handy 
for testing.

The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
be passed in.

I created branch {{HTTPCORE-569}} with a proposal.

You use this by calling 
{{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.


  was:
Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
lookup values without an exact match override: This allows path matches 
_without_ having an exact match override the order in which the patterns are 
defined (which is the current behavior.)

This is a request from some of my users at work, they just want to a list of 
URI patterns in a specific order which is observed no matter what. Very handy 
for testing.

The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
be passed in.

I'll create a branch with a proposal.

You use this by calling 
{{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.



> Create new value in org.apache.hc.core5.http.protocol.UriPatternType to 
> lookup without an exact match override
> --
>
> Key: HTTPCORE-569
> URL: https://issues.apache.org/jira/browse/HTTPCORE-569
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
> lookup values without an exact match override: This allows path matches 
> _without_ having an exact match override the order in which the patterns are 
> defined (which is the current behavior.)
> This is a request from some of my users at work, they just want to a list of 
> URI patterns in a specific order which is observed no matter what. Very handy 
> for testing.
> The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
> be passed in.
> I created branch {{HTTPCORE-569}} with a proposal.
> You use this by calling 
> {{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-570) Add getters to AsyncServerBootstrap and refactor create() impl into protected methods

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-570:
-

 Summary: Add getters to AsyncServerBootstrap and refactor create() 
impl into protected methods
 Key: HTTPCORE-570
 URL: https://issues.apache.org/jira/browse/HTTPCORE-570
 Project: HttpComponents HttpCore
  Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory


Add getters to {{AsyncServerBootstrap}} and refactor {{create()}} 
implementation into protected methods.

Right now, you can subclass {{AsyncServerBootstrap}} to customize a 
{{create()}} method but you cannot get to instance variables as these are 
private.

The goal is to make creating instances of {{HttpAsyncServer}} simpler by adding 
getters and refactoring create() implementations into protected methods such 
that subclasses can more simply create custom instances.

That does not seem controversial to me so I am not sure a feature branch is 
needed but I'll create one anyway.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCORE-569) Create new value in org.apache.hc.core5.http.protocol.UriPatternType to lookup without an exact match override

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCORE-569:
--
Description: 
Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
lookup values without an exact match override: This allows path matches 
_without_ having an exact match override the order in which the patterns are 
defined (which is the current behavior.)

This is a request from some of my users at work, they just want to a list of 
URI patterns in a specific order which is observed no matter what. Very handy 
for testing.

The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
be passed in.

I'll create a branch with a proposal.

You use this by calling 
{{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.


  was:
Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
lookup values without an exact match override: This allows path matches 
_without_ having an exact match override the order in which the patterns are 
defined (which is the current behavior.)

This is a request from some of my users at work, they just want to a list of 
URI patterns in a specific order which is observed no matter what. Very handy 
for testing.

The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
be passed in.

I'll create a branch with a proposal.



> Create new value in org.apache.hc.core5.http.protocol.UriPatternType to 
> lookup without an exact match override
> --
>
> Key: HTTPCORE-569
> URL: https://issues.apache.org/jira/browse/HTTPCORE-569
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
> lookup values without an exact match override: This allows path matches 
> _without_ having an exact match override the order in which the patterns are 
> defined (which is the current behavior.)
> This is a request from some of my users at work, they just want to a list of 
> URI patterns in a specific order which is observed no matter what. Very handy 
> for testing.
> The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
> be passed in.
> I'll create a branch with a proposal.
> You use this by calling 
> {{org.apache.hc.core5.http.impl.bootstrap.AsyncServerBootstrap.setUriPatternType(UriPatternType)}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-569) Create new value in org.apache.hc.core5.http.protocol.UriPatternType to lookup without an exact match override

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-569:
-

 Summary: Create new value in 
org.apache.hc.core5.http.protocol.UriPatternType to lookup without an exact 
match override
 Key: HTTPCORE-569
 URL: https://issues.apache.org/jira/browse/HTTPCORE-569
 Project: HttpComponents HttpCore
  Issue Type: New Feature
  Components: HttpCore
Reporter: Gary Gregory
Assignee: Gary Gregory


Create new value in {{org.apache.hc.core5.http.protocol.UriPatternType}} to 
lookup values without an exact match override: This allows path matches 
_without_ having an exact match override the order in which the patterns are 
defined (which is the current behavior.)

This is a request from some of my users at work, they just want to a list of 
URI patterns in a specific order which is observed no matter what. Very handy 
for testing.

The implementation would refactor {{UriPatternMatcher}} to allow a boolean to 
be passed in.

I'll create a branch with a proposal.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Comment Edited] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758301#comment-16758301
 ] 

Gary Gregory edited comment on HTTPCLIENT-1968 at 2/1/19 1:39 PM:
--

Hi All.

I am thinking about moving forward here and how to help Here is a possible path 
forward:
 * State a specific use case with a unit test
 * Propose a patch _which does not break binary compatibility_
 * Ideally these are new APIs like {{setThisKindOfPath}}
 * It might be possible to workaround this with documentation. Is it?

Then we can move away from changing the behavior of the current API to adding 
APIs you can use and discuss if your patch fits in here.

Thoughts?


was (Author: garydgregory):
Hi All.

I am thinking about moving forward here and how to help Here is a possible path 
forward:
 * State a specific use case with a unit test
 * Propose a patch _which does not break binary compatibility_

Then we can move away from changing the behavior of the current API to adding 
APIs you can use and discuss if your patch fits in here.

Thoughts?

> Encoded forward slashes are not preserved when rewriting URI
> 
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.7
>Reporter: Jay Modi
>Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when 
> the HTTP client executes. I came across this when upgrading from 4.5.2 to 
> 4.5.7 and my requests that contained an encoded forward slash suddenly 
> started failing. The appears to be due to decoding and re-encoding of the 
> path that takes place in the URIUtils#rewriteURI method. I've attached a 
> patch that restores the old behavior but if a URI contains two slashes in a 
> row in addition to an encoded slash the encoded forward slash will be decoded.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1968) Encoded forward slashes are not preserved when rewriting URI

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758301#comment-16758301
 ] 

Gary Gregory commented on HTTPCLIENT-1968:
--

Hi All.

I am thinking about moving forward here and how to help Here is a possible path 
forward:
 * State a specific use case with a unit test
 * Propose a patch _which does not break binary compatibility_

Then we can move away from changing the behavior of the current API to adding 
APIs you can use and discuss if your patch fits in here.

Thoughts?

> Encoded forward slashes are not preserved when rewriting URI
> 
>
> Key: HTTPCLIENT-1968
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1968
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.7
>Reporter: Jay Modi
>Priority: Major
> Attachments: rewrite_preserve_forward_slash.diff
>
>
> URIs that contain an encoded forward slash (%2F) are no longer preserved when 
> the HTTP client executes. I came across this when upgrading from 4.5.2 to 
> 4.5.7 and my requests that contained an encoded forward slash suddenly 
> started failing. The appears to be due to decoding and re-encoding of the 
> path that takes place in the URIUtils#rewriteURI method. I've attached a 
> patch that restores the old behavior but if a URI contains two slashes in a 
> row in addition to an encoded slash the encoded forward slash will be decoded.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1960) URIBuilder incorrect handling of multiple leading slashes in path component

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756327#comment-16756327
 ] 

Gary Gregory commented on HTTPCLIENT-1960:
--

I'm not sure I buy the component size argument. The right home is the right 
home IMO, here or in Commons.

> URIBuilder incorrect handling of multiple leading slashes in path component
> ---
>
> Key: HTTPCLIENT-1960
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1960
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.5
>Reporter: Raymond Cuenen
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.5.7, 5.0 Beta4
>
>
> If original path startsWith '/' it is removed by normalizePath; in that case 
> it should be added again URI-encoded. For example: A path value of 
> '/etc/motd' becomes:
> {code:java}
> ftp://myn...@host.dom/etc/motd{code}
> while it should be:
> {code:java}
> ftp://myn...@host.dom/%2Fetc/motd{code}
> Only when the path value is 'etc/motd' is should become 
> "ftp://myn...@host.dom/etc/motd;
>   
> Fix for this issue in URIBuilder.java:
> {noformat}
> private String buildString() {
> ...
> if (this.encodedPath != null) {
> sb.append(normalizePath(this.encodedPath, sb.length() == 0));
> } else if (this.path != null) {
> String encodedPath = encodePath(normalizePath(this.path, sb.length() 
> == 0));
> // Start fix for paths starting with '/'
> // If original path startsWith '/' it is removed by normalizePath; in 
> that case it should be added again URI-encoded.
> if (this.path.startsWith("/")) {
> encodedPath = "/%2F" + encodedPath.substring(1);
> }
> // End fix
> sb.append(encodedPath);
> }
> ...
> }{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1960) URIBuilder incorrect handling of multiple leading slashes in path component

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741899#comment-16741899
 ] 

Gary Gregory commented on HTTPCLIENT-1960:
--

[~michael-o] What is the alternative you propose? A new project? What else 
would be in it? Eventually that project would grow and people would ask the 
same question: I have pull in that project just to get the one class? Sure 
there is also Apache Commons Net and Commons Lang, which could be a home for 
such a class, but then what? Would you make HttoClient depend on one of those? 
I would think that a new URI class might be handy to use within HttpCore and 
HttpClient if the one provided by the JRE is so old.

> URIBuilder incorrect handling of multiple leading slashes in path component
> ---
>
> Key: HTTPCLIENT-1960
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1960
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.5
>Reporter: Raymond Cuenen
>Assignee: Oleg Kalnichevski
>Priority: Major
>
> If original path startsWith '/' it is removed by normalizePath; in that case 
> it should be added again URI-encoded. For example: A path value of 
> '/etc/motd' becomes:
> {code:java}
> ftp://myn...@host.dom/etc/motd{code}
> while it should be:
> {code:java}
> ftp://myn...@host.dom/%2Fetc/motd{code}
> Only when the path value is 'etc/motd' is should become 
> "ftp://myn...@host.dom/etc/motd;
>   
> Fix for this issue in URIBuilder.java:
> {noformat}
> private String buildString() {
> ...
> if (this.encodedPath != null) {
> sb.append(normalizePath(this.encodedPath, sb.length() == 0));
> } else if (this.path != null) {
> String encodedPath = encodePath(normalizePath(this.path, sb.length() 
> == 0));
> // Start fix for paths starting with '/'
> // If original path startsWith '/' it is removed by normalizePath; in 
> that case it should be added again URI-encoded.
> if (this.path.startsWith("/")) {
> encodedPath = "/%2F" + encodedPath.substring(1);
> }
> // End fix
> sb.append(encodedPath);
> }
> ...
> }{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1960) URIBuilder incorrect handling of multiple leading slashes in path component

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741657#comment-16741657
 ] 

Gary Gregory commented on HTTPCLIENT-1960:
--

[~michael-o] HttpCore is it, there is no "top-level" Apache project.

> URIBuilder incorrect handling of multiple leading slashes in path component
> ---
>
> Key: HTTPCLIENT-1960
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1960
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.5
>Reporter: Raymond Cuenen
>Assignee: Oleg Kalnichevski
>Priority: Major
>
> If original path startsWith '/' it is removed by normalizePath; in that case 
> it should be added again URI-encoded. For example: A path value of 
> '/etc/motd' becomes:
> {code:java}
> ftp://myn...@host.dom/etc/motd{code}
> while it should be:
> {code:java}
> ftp://myn...@host.dom/%2Fetc/motd{code}
> Only when the path value is 'etc/motd' is should become 
> "ftp://myn...@host.dom/etc/motd;
>   
> Fix for this issue in URIBuilder.java:
> {noformat}
> private String buildString() {
> ...
> if (this.encodedPath != null) {
> sb.append(normalizePath(this.encodedPath, sb.length() == 0));
> } else if (this.path != null) {
> String encodedPath = encodePath(normalizePath(this.path, sb.length() 
> == 0));
> // Start fix for paths starting with '/'
> // If original path startsWith '/' it is removed by normalizePath; in 
> that case it should be added again URI-encoded.
> if (this.path.startsWith("/")) {
> encodedPath = "/%2F" + encodedPath.substring(1);
> }
> // End fix
> sb.append(encodedPath);
> }
> ...
> }{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1960) URIBuilder incorrect handling of multiple leading slashes in path component

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741603#comment-16741603
 ] 

Gary Gregory commented on HTTPCLIENT-1960:
--

Should we then implement our own URI class for the current RFC?

> URIBuilder incorrect handling of multiple leading slashes in path component
> ---
>
> Key: HTTPCLIENT-1960
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1960
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.5
>Reporter: Raymond Cuenen
>Assignee: Oleg Kalnichevski
>Priority: Major
>
> If original path startsWith '/' it is removed by normalizePath; in that case 
> it should be added again URI-encoded. For example: A path value of 
> '/etc/motd' becomes:
> {code:java}
> ftp://myn...@host.dom/etc/motd{code}
> while it should be:
> {code:java}
> ftp://myn...@host.dom/%2Fetc/motd{code}
> Only when the path value is 'etc/motd' is should become 
> "ftp://myn...@host.dom/etc/motd;
>   
> Fix for this issue in URIBuilder.java:
> {noformat}
> private String buildString() {
> ...
> if (this.encodedPath != null) {
> sb.append(normalizePath(this.encodedPath, sb.length() == 0));
> } else if (this.path != null) {
> String encodedPath = encodePath(normalizePath(this.path, sb.length() 
> == 0));
> // Start fix for paths starting with '/'
> // If original path startsWith '/' it is removed by normalizePath; in 
> that case it should be added again URI-encoded.
> if (this.path.startsWith("/")) {
> encodedPath = "/%2F" + encodedPath.substring(1);
> }
> // End fix
> sb.append(encodedPath);
> }
> ...
> }{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-566) Thread spinning at ChunkEncoder.write method

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16737307#comment-16737307
 ] 

Gary Gregory commented on HTTPCORE-566:
---

What happens with the current 4.4.10 version for your use case?

> Thread spinning at ChunkEncoder.write method
> 
>
> Key: HTTPCORE-566
> URL: https://issues.apache.org/jira/browse/HTTPCORE-566
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: Stuck
>Reporter: M0nika
>Priority: Major
> Attachments: Error-logs.txt
>
>
> My application is using the HttpCore-nio-4.3.3 component.I am facing the a 
> thread spinning issue related to HTTP Core dependency.I have attached the log 
> file. 
> I found the same issue is reported in apache mail archive for the httpcore 
> 4.3.3.
> https://www.mail-archive.com/dev@hc.apache.org/msg17340.html
> In which they have provided the below solution to resolved this issue:
> *After replacing the while loop in the ChunkEncorder  with a if statement, we 
> were able to solve the thread spinning issue. However, we couldn't figure out 
> the root cause that makes the while loop spin forever.*
> https://www.mail-archive.com/dev@hc.apache.org/msg17563.html
> But in the master branch of httpcore this fixed is not present in 
> ChunkEncoder file.Please let me know this issue is fixed in latest releases 
> or not?
> If it is fixed please help me to know where you have fixed this issue in 
> httpcore.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1954) Getting Connection Reset and Read timeout with httpclient 4.5.5

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16715643#comment-16715643
 ] 

Gary Gregory commented on HTTPCLIENT-1954:
--

Hi [~SandraH],

May you test with version 4.5.6 and report back please?

Gary

> Getting Connection Reset and Read timeout with httpclient 4.5.5
> ---
>
> Key: HTTPCLIENT-1954
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1954
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 4.5.5
>Reporter: Sandra
>Priority: Major
>  Labels: performance
>
> Hello,
>  
> I've been using the httpclient-4.5.5. jar library to create HTTP connections 
> and it has been implemented in production environment, but the user is 
> getting Connection reset and Read time out exeptions...
>  
> Do you know something about this kind of exceptions with the 4.5.5 library?
>  
> java.net.SocketException: Connection reset
>     at java.net.SocketInputStream.read(SocketInputStream.java:196)
>     at java.net.SocketInputStream.read(SocketInputStream.java:122)
>     at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
>     at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
>     at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
>     at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
>     at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
>     at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
>     at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
>     at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
>     at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
>     at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
>     at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
>     at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
>     at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
>     at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
>     at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
>     at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
>     at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
>     at 
> com.hp.vzw.spc.nrb.util.HistoricalRequestWork.call(HistoricalRequestWork.java:177)
>     at 
> com.hp.vzw.spc.nrb.util.HistoricalRequestWork.call(HistoricalRequestWork.java:33)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>     at java.lang.Thread.run(Thread.java:745)
> Dec 04, 2018 18:48:49 PM [pool-1-thread-25
>  
> The method to create the connections:
> {color:#7f0055}*public*{color} CloseableHttpClient 
> createHttpClientHistorical(*{color:#7f0055}int{color}* 
> {color:#6a3e3e}JSONTimeout{color})
> {
> _{color:#c0}logger{color}_.info({color:#2a00ff}"Creating http client 
> JSONTimeout value received: "{color}+ {color:#6a3e3e}JSONTimeout{color});
> *{color:#7f0055}int{color}* {color:#6a3e3e}jsonTimeout{color};
> *{color:#7f0055}if{color}* ({color:#6a3e3e}JSONTimeout{color} == 0){
> {color:#6a3e3e}jsonTimeout{color} = 
> Integer.parseInt(getPropertyFromFile({color:#2a00ff}"JSONTIMEOUT"{color}).trim());
> _{color:#c0}logger{color}_.info({color:#2a00ff}"Setting JSONTimeout from 
> file: "{color}+ {color:#6a3e3e}jsonTimeout{color});
> }
> *{color:#7f0055}else{color}*{
> {color:#6a3e3e}jsonTimeout{color} = {color:#6a3e3e}JSONTimeout{color};
> _{color:#c0}logger{color}_.info({color:#2a00ff}"Setting JSONTimeout from 
> screen: "{color}+ {color:#6a3e3e}jsonTimeout{color});
> }
>  RequestConfig {color:#6a3e3e}defaultRequestConfig{color} = 
> RequestConfig.custom()
>  .setConnectTimeout({color:#6a3e3e}jsonTimeout{color})
>  .setSocketTimeout({color:#6a3e3e}jsonTimeout{color})
>  .setConnectionRequestTimeout({color:#6a3e3e}jsonTimeout{color})
> .build();
>  CloseableHttpClient {color:#6a3e3e}httpClient{color} = HttpClients.custom() 
>  

[jira] [Commented] (HTTPCORE-564) Eliminate a deadlock in IOReactor

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711588#comment-16711588
 ] 

Gary Gregory commented on HTTPCORE-564:
---

You cannot make an official release but you can build the project locally from 
a clone of the git repo:
{quote}mvn clean install
{quote}
 

> Eliminate a deadlock in IOReactor
> -
>
> Key: HTTPCORE-564
> URL: https://issues.apache.org/jira/browse/HTTPCORE-564
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 4.4.10
>Reporter: Max Rozhkov
>Assignee: Oleg Kalnichevski
>Priority: Major
>
> *User Story*
> We use async http client in very high load environment where several 
> thousands of http requests are sent per second. It is an SSP service where 
> timeout has to be measured and a request to be voided after timeout.
> We set up usual timeouts configured in IO Reactor and control timeouts 
> externally as well. When time is out the request will be cancelled explicitly 
> with _AbstractExecutionAwareRequest.abort()_.
> *Problem description*
> Deadlock could happen in very highload environment. See stack information 
> below.
> *Stack trace*
> {{"timeout-controller-0-00":}}
> {{ at 
> java.nio.channels.spi.AbstractInterruptibleChannel.close(java.base@11.0.1/AbstractInterruptibleChannel.java:108)}}
> {{ - waiting to lock <0x00112c420bd0> (a java.lang.Object)}}
> {{ at 
> org.apache.http.impl.nio.reactor.IOSessionImpl.close(IOSessionImpl.java:227)}}
> {{ - locked <0x00112c420be0> (a sun.nio.ch.SelectionKeyImpl)}}
> {{ at 
> org.apache.http.impl.nio.reactor.IOSessionImpl.shutdown(IOSessionImpl.java:255)}}
> {{ at 
> org.apache.http.impl.nio.NHttpConnectionBase.shutdown(NHttpConnectionBase.java:579)}}
> {{ at 
> org.apache.http.impl.nio.conn.CPoolEntry.shutdownConnection(CPoolEntry.java:80)}}
> {{ at org.apache.http.impl.nio.conn.CPoolProxy.shutdown(CPoolProxy.java:91)}}
> {{ at 
> org.apache.http.impl.nio.client.AbstractClientExchangeHandler.discardConnection(AbstractClientExchangeHandler.java:267)}}
> {{ at 
> org.apache.http.impl.nio.client.AbstractClientExchangeHandler.cancel(AbstractClientExchangeHandler.java:447)}}
> {{ at 
> org.apache.http.client.methods.AbstractExecutionAwareRequest.abort(AbstractExecutionAwareRequest.java:90)}}
> {{ at 
> net.thumbtack.ssp.requester.AsyncHttpClient.lambda$execute$1(AsyncHttpClient.java:83)}}
> {{ at 
> net.thumbtack.ssp.requester.AsyncHttpClient$$Lambda$1768/0x0017c29f6440.run(Unknown
>  Source)}}
> {{ at 
> net.thumbtack.adtech.concurrent.TimeLimitedExecution.lambda$future$1(TimeLimitedExecution.java:70)}}
> {{ at 
> net.thumbtack.adtech.concurrent.TimeLimitedExecution$$Lambda$1770/0x0017c29f6c40.run(Unknown
>  Source)}}
> {{ at 
> net.thumbtack.adtech.concurrent.TimeoutController.check(TimeoutController.java:47)}}
> {{ at 
> net.thumbtack.adtech.concurrent.TimeoutController$$Lambda$1022/0x0017c28acc40.run(Unknown
>  Source)}}
> {{ at 
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.1/Executors.java:515)}}
> {{ at 
> java.util.concurrent.FutureTask.runAndReset(java.base@11.0.1/FutureTask.java:305)}}
> {{ at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@11.0.1/ScheduledThreadPoolExecutor.java:305)}}
> {{ at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.1/ThreadPoolExecutor.java:1128)}}
> {{ at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.1/ThreadPoolExecutor.java:628)}}
> {{ at java.lang.Thread.run(java.base@11.0.1/Thread.java:834)}}
> {{"pool-21-thread-1":}}
> {{ at 
> java.nio.channels.spi.AbstractSelectionKey.cancel(java.base@11.0.1/AbstractSelectionKey.java:70)}}
> {{ - waiting to lock <0x00112c420be0> (a sun.nio.ch.SelectionKeyImpl)}}
> {{ at 
> java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(java.base@11.0.1/AbstractSelectableChannel.java:255)}}
> {{ at 
> java.nio.channels.spi.AbstractInterruptibleChannel.close(java.base@11.0.1/AbstractInterruptibleChannel.java:112)}}
> {{ - locked <0x00112c420bd0> (a java.lang.Object)}}
> {{ at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.doShutdown(AbstractMultiworkerIOReactor.java:414)}}
> {{ at 
> org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor.execute(AbstractMultiworkerIOReactor.java:374)}}
> {{ at 
> org.apache.http.impl.nio.conn.PoolingNHttpClientConnectionManager.execute(PoolingNHttpClientConnectionManager.java:221)}}
> {{ at 
> org.apache.http.impl.nio.client.CloseableHttpAsyncClientBase$1.run(CloseableHttpAsyncClientBase.java:64)}}
> {{ at java.lang.Thread.run(java.base@11.0.1/Thread.java:834) }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: 

[jira] [Commented] (HTTPCLIENT-1952) Allow default User Agent to be disabled

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710624#comment-16710624
 ] 

Gary Gregory commented on HTTPCLIENT-1952:
--

Well, can someone propose a PR? ;-) With tests double ;-)

> Allow default User Agent to be disabled
> ---
>
> Key: HTTPCLIENT-1952
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1952
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.5.6
>Reporter: Antony Bowesman
>Priority: Minor
>
> There is no way to disable the User-Agent header. In any kind of micro 
> service architecture, where UA header is irrelevant, the header cannot be 
> removed.
> This has been seen as an issue using JMeter, see link
> [https://bz.apache.org/bugzilla/show_bug.cgi?id=62977#c1]
> See comment #1 there from [~michael-o] 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1952) Allow default User Agent to be disabled

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710464#comment-16710464
 ] 

Gary Gregory commented on HTTPCLIENT-1952:
--

That brings up the general case: Should we have a more general setting like 
{{enableHeader(String headerName, boolean enable)}}, so you could say 
{{enableHeader("User-Agent", false)}} where there is a suitable String constant 
someplace in HttpCore or Client.

Gary

> Allow default User Agent to be disabled
> ---
>
> Key: HTTPCLIENT-1952
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1952
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.5.6
>Reporter: Antony Bowesman
>Priority: Minor
>
> There is no way to disable the User-Agent header. In any kind of micro 
> service architecture, where UA header is irrelevant, the header cannot be 
> removed.
> This has been seen as an issue using JMeter, see link
> [https://bz.apache.org/bugzilla/show_bug.cgi?id=62977#c1]
> See comment #1 there from [~michael-o] 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1952) Allow default User Agent to be disabled

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710351#comment-16710351
 ] 

Gary Gregory commented on HTTPCLIENT-1952:
--

Or we could redefine what it means to pass {{null}} to {{setUserAgent()}}, it 
seems OK to me to say "null means ignore".

Gary

> Allow default User Agent to be disabled
> ---
>
> Key: HTTPCLIENT-1952
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1952
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpCache
>Affects Versions: 4.5.6
>Reporter: Antony Bowesman
>Priority: Minor
>
> There is no way to disable the User-Agent header. In any kind of micro 
> service architecture, where UA header is irrelevant, the header cannot be 
> removed.
> This has been seen as an issue using JMeter, see link
> [https://bz.apache.org/bugzilla/show_bug.cgi?id=62977#c1]
> See comment #1 there from [~michael-o] 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-562) The reason phrase returned by org.apache.hc.core5.http.HttpResponse.getReasonPhrase() may be empty.

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-562.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta6
   4.4.11

In git master and 4.4.x.

> The reason phrase returned by 
> org.apache.hc.core5.http.HttpResponse.getReasonPhrase() may be empty.
> ---
>
> Key: HTTPCORE-562
> URL: https://issues.apache.org/jira/browse/HTTPCORE-562
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 4.4.10, 5.0-beta5
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.11, 5.0-beta6
>
>
> The reason phrase returned by 
> {{org.apache.hc.core5.http.HttpResponse.getReasonPhrase()}} may be empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-562) The reason phrase returned by org.apache.hc.core5.http.HttpResponse.getReasonPhrase() may be empty.

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-562:
-

 Summary: The reason phrase returned by 
org.apache.hc.core5.http.HttpResponse.getReasonPhrase() may be empty.
 Key: HTTPCORE-562
 URL: https://issues.apache.org/jira/browse/HTTPCORE-562
 Project: HttpComponents HttpCore
  Issue Type: Bug
  Components: HttpCore
Affects Versions: 5.0-beta5, 4.4.10
Reporter: Gary Gregory
Assignee: Gary Gregory


The reason phrase returned by 
{{org.apache.hc.core5.http.HttpResponse.getReasonPhrase()}} may be empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1947) Update JNA from 4.5.2 to 5.0.0

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCLIENT-1947:
-
Affects Version/s: (was: 4.5.6)
   5.0 Beta1

> Update JNA from 4.5.2 to 5.0.0
> --
>
> Key: HTTPCLIENT-1947
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1947
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (Windows)
>Affects Versions: 5.0 Beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Update JNA from 4.5.2 to 5.0.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1947) Update JNA from 4.5.2 to 5.0.0

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCLIENT-1947.

   Resolution: Fixed
Fix Version/s: (was: 4.5.7)
   5.0 Beta2

In git master.

> Update JNA from 4.5.2 to 5.0.0
> --
>
> Key: HTTPCLIENT-1947
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1947
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (Windows)
>Affects Versions: 4.5.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Update JNA from 4.5.2 to 5.0.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1947) Update JNA from 4.5.2 to 5.0.0

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCLIENT-1947:


 Summary: Update JNA from 4.5.2 to 5.0.0
 Key: HTTPCLIENT-1947
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1947
 Project: HttpComponents HttpClient
  Issue Type: Improvement
  Components: HttpClient (Windows)
Affects Versions: 4.5.6
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 4.5.7


Update JNA from 4.5.2 to 5.0.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1946) Support relatively new HTTP 308 redirect - RFC7538

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650436#comment-16650436
 ] 

Gary Gregory commented on HTTPCLIENT-1946:
--

Hi [~davidpel],

If you want to patch up version 4, then please free to submit a PR on GitHub, 
with unit tests of course ;) It think this would be welcome by our community.

Gary

> Support relatively new HTTP 308 redirect - RFC7538
> --
>
> Key: HTTPCLIENT-1946
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1946
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 3.1 (end of life), 4.5.6
> Environment: Irrelevant
>Reporter: David Peleg
>Priority: Major
>  Labels: easyfix, usability
>
> RFC7538 added a new HTTP redirect code: 308.
>  
> To support it all you need is adding 2 rows:
>  # In HttpStatus add constant: SC_PERMANENT_REDIRECT = 308
>  # In HttpMethodDirector.isRedirectNeeded() (in version 3.x) add 
> SC_PERMANENT_REDIRECT to the switch clause.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1946) Support relatively new HTTP 308 redirect - RFC7538

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650416#comment-16650416
 ] 

Gary Gregory commented on HTTPCLIENT-1946:
--

[~davidpel]:

More HTTP status codes have been added to httpcore-5.0-beta4-RC1. A subsequent 
HttpClient 5.0-beta will then depend on httpcore-5.0-beta4, which should happen 
soonish.

Specifically, HTTPCORE-552, HTTPCORE-553, HTTPCORE-554, HTTPCORE-555, 
HTTPCORE-556, HTTPCORE-557, HTTPCORE-558: added status codes 103, 208, 226, 
308, 451, 506, 508, 510

You can test it here: 
https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.0-beta4-RC1/

This will not do you much good unless you clone and checkout the git master of 
HttpClient and build it with httpcore-5.0-beta4, which may require code changes.

Alternatively, you can wait for the next beta of HttpClient 5. This might be 
the least complicated option for you depending on your level of urgency.

Gary

> Support relatively new HTTP 308 redirect - RFC7538
> --
>
> Key: HTTPCLIENT-1946
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1946
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 3.1 (end of life), 4.5.6
> Environment: Irrelevant
>Reporter: David Peleg
>Priority: Major
>  Labels: easyfix, usability
>
> RFC7538 added a new HTTP redirect code: 308.
>  
> To support it all you need is adding 2 rows:
>  # In HttpStatus add constant: SC_PERMANENT_REDIRECT = 308
>  # In HttpMethodDirector.isRedirectNeeded() (in version 3.x) add 
> SC_PERMANENT_REDIRECT to the switch clause.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1946) Support relatively new HTTP 308 redirect - RFC7538

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650345#comment-16650345
 ] 

Gary Gregory commented on HTTPCLIENT-1946:
--

Did you really mean to create this ticket for version 3.1 which is EOL?

Gary

> Support relatively new HTTP 308 redirect - RFC7538
> --
>
> Key: HTTPCLIENT-1946
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1946
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 3.1 (end of life)
> Environment: Irrelevant
>Reporter: David Peleg
>Priority: Major
>  Labels: easyfix, usability
> Fix For: 3.1 (end of life)
>
>
> RFC7538 added a new HTTP redirect code: 308.
>  
> To support it all you need is adding 2 rows:
>  # In HttpStatus add constant: SC_PERMANENT_REDIRECT = 308
>  # In HttpMethodDirector.isRedirectNeeded() add SC_PERMANENT_REDIRECT to the 
> switch clause.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1942) Add support for Reactive Streams

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622895#comment-16622895
 ] 

Gary Gregory commented on HTTPCLIENT-1942:
--

Hi [~rschmitt] and thank you for your contribution.

IMO, this kind of code:

{code:java}
@Override
public int available() {
final ReactiveDataProducer p = responseProducer.get();
if (p == null) {
return 0;
} else {
return p.available();
}
}
{code}

is better like this:

{code:java}
@Override
public int available() {
final ReactiveDataProducer p = responseProducer.get();
return p == null ? 0 : p.available();
}
{code}

Java is verbose enough as it is ;-)

Gary


> Add support for Reactive Streams
> 
>
> Key: HTTPCLIENT-1942
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1942
> Project: HttpComponents HttpClient
>  Issue Type: Wish
>  Components: HttpClient (async)
>Affects Versions: 5.0 Beta1
>Reporter: Ryan Schmitt
>Priority: Major
>  Labels: stuck, volunteers-wanted
> Fix For: Future
>
> Attachments: client to server tput.jpeg, client to server window 
> scaling (bytes out).jpeg, server to client tput.jpeg
>
>
> It would be very helpful to me if the Apache client provided an 
> implementation of the [Reactive Streams|http://www.reactive-streams.org/] 
> spec, particularly as an implementation of the standard 
> [interfaces|https://search.maven.org/artifact/org.reactivestreams/reactive-streams/1.0.2/jar].
>  These interfaces are JDK6-compatible and have no other dependencies, but 
> they unlock interoperability with many other frameworks, such as RxJava.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-550) When a ParseException is caught and rethrown as an IOException in org.apache.http.impl.nio.codecs.ChunkDecoder.processFooters(), the IOException does not chain the origi

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-550.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3
   4.4.11

> When a ParseException is caught and rethrown as an IOException in 
> org.apache.http.impl.nio.codecs.ChunkDecoder.processFooters(), the 
> IOException does not chain the original ParseException
> ---
>
> Key: HTTPCORE-550
> URL: https://issues.apache.org/jira/browse/HTTPCORE-550
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore NIO
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.11, 5.0-beta3
>
>
> When a {{ParseException}} is caught and rethrown as an {{IOException}} in 
> org.apache.http.impl.nio.codecs.ChunkDecoder.processFooters(), the 
> {{IOException}} does not chain the original {{ParseException}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-550) When a ParseException is caught and rethrown as an IOException in org.apache.http.impl.nio.codecs.ChunkDecoder.processFooters(), the IOException does not chain the orig

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-550:
-

 Summary: When a ParseException is caught and rethrown as an 
IOException in org.apache.http.impl.nio.codecs.ChunkDecoder.processFooters(), 
the IOException does not chain the original ParseException
 Key: HTTPCORE-550
 URL: https://issues.apache.org/jira/browse/HTTPCORE-550
 Project: HttpComponents HttpCore
  Issue Type: Improvement
  Components: HttpCore NIO
Reporter: Gary Gregory
Assignee: Gary Gregory


When a {{ParseException}} is caught and rethrown as an {{IOException}} in 
org.apache.http.impl.nio.codecs.ChunkDecoder.processFooters(), the 
{{IOException}} does not chain the original {{ParseException}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1939) Update Apache Commons Codec from 1.10 to 1.11

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCLIENT-1939.

   Resolution: Fixed
Fix Version/s: 4.5.7

In git {{master}} and branch {{4.5.x}}.

> Update Apache Commons Codec from 1.10 to 1.11
> -
>
> Key: HTTPCLIENT-1939
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1939
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 5.0 Beta1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.5.7, 5.0 Beta2
>
>
> Update Apache Commons Codec from 1.10 to 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1939) Update Apache Commons Codec from 1.10 to 1.11

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCLIENT-1939:


 Summary: Update Apache Commons Codec from 1.10 to 1.11
 Key: HTTPCLIENT-1939
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1939
 Project: HttpComponents HttpClient
  Issue Type: Improvement
Affects Versions: 5.0 Beta1
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 5.0 Beta2


Update Apache Commons Codec from 1.10 to 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCORE-548) Add missing HttpContext parameter to APIs

[Gary Gregory (JIRA)]

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

Gary Gregory resolved HTTPCORE-548.
---
Resolution: Fixed

Setting to resolved for now.

> Add missing HttpContext parameter to APIs
> -
>
> Key: HTTPCORE-548
> URL: https://issues.apache.org/jira/browse/HTTPCORE-548
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore NIO
>Affects Versions: 5.0-beta2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add missing HttpContext parameter to APIs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-548) Add missing HttpContext parameter to APIs

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-548:
-

 Summary: Add missing HttpContext parameter to APIs
 Key: HTTPCORE-548
 URL: https://issues.apache.org/jira/browse/HTTPCORE-548
 Project: HttpComponents HttpCore
  Issue Type: New Feature
  Components: HttpCore NIO
Affects Versions: 5.0-beta2
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 5.0-beta3


Add missing HttpContext parameter to APIs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-547) Update org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(String) to return a boolean

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-547.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3

In git master.

> Update org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(String) to 
> return a boolean
> -
>
> Key: HTTPCORE-547
> URL: https://issues.apache.org/jira/browse/HTTPCORE-547
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Update {{org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(String)}} 
> to return a boolean: {{true}} if any header was removed as a result of this 
> call.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-547) Update org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(String) to return a boolean

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-547:
-

 Summary: Update 
org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(String) to return a 
boolean
 Key: HTTPCORE-547
 URL: https://issues.apache.org/jira/browse/HTTPCORE-547
 Project: HttpComponents HttpCore
  Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory


Update {{org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(String)}} 
to return a boolean: {{true}} if any header was removed as a result of this 
call.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-546) Update org.apache.hc.core5.http.message.HeaderGroup.removeHeader(Header) to return a boolean

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-546.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3

In git master.

> Update org.apache.hc.core5.http.message.HeaderGroup.removeHeader(Header) to 
> return a boolean
> 
>
> Key: HTTPCORE-546
> URL: https://issues.apache.org/jira/browse/HTTPCORE-546
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Update {{org.apache.hc.core5.http.message.HeaderGroup.removeHeader(Header)}} 
> to return a boolean: {{true}} if a header was removed as a result of this 
> call.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-545) Add org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(Header)

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-545.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3

In git master.

> Add org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(Header)
> --
>
> Key: HTTPCORE-545
> URL: https://issues.apache.org/jira/browse/HTTPCORE-545
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add {{org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(Header)}} to 
> remove ALL headers that match the given header.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-546) Update org.apache.hc.core5.http.message.HeaderGroup.removeHeader(Header) to return a boolean

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-546:
-

 Summary: Update 
org.apache.hc.core5.http.message.HeaderGroup.removeHeader(Header) to return a 
boolean
 Key: HTTPCORE-546
 URL: https://issues.apache.org/jira/browse/HTTPCORE-546
 Project: HttpComponents HttpCore
  Issue Type: New Feature
  Components: HttpCore
Reporter: Gary Gregory
Assignee: Gary Gregory


Update {{org.apache.hc.core5.http.message.HeaderGroup.removeHeader(Header)}} to 
return a boolean: {{true}} if a header was removed as a result of this call.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-545) Add org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(Header)

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-545:
-

 Summary: Add 
org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(Header)
 Key: HTTPCORE-545
 URL: https://issues.apache.org/jira/browse/HTTPCORE-545
 Project: HttpComponents HttpCore
  Issue Type: New Feature
  Components: HttpCore
Reporter: Gary Gregory
Assignee: Gary Gregory


Add {{org.apache.hc.core5.http.message.HeaderGroup.removeHeaders(Header)}} to 
remove ALL headers that match the given header.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-544) Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558859#comment-16558859
 ] 

Gary Gregory commented on HTTPCORE-544:
---

Hi Oleg,

{quote}
Socket timeout in EndpointDetails still looks wrong to me but I leave it up to 
you if you want to keep it or not.
{quote}

If it feels like the wrong home to you, where should it go? 

IOW: Where can I get the current connection's timeout (from a client or to an 
origin server) from an HttpRequest and HttpContext, for example, when you 
implement 
{{org.apache.hc.core5.http.nio.AsyncServerExchangeHandler.handleRequest(HttpRequest,
 EntityDetails, ResponseChannel, HttpContext)}}?

Thank you,
Gary

> Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()
> ---
>
> Key: HTTPCORE-544
> URL: https://issues.apache.org/jira/browse/HTTPCORE-544
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add {{org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-544) Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558783#comment-16558783
 ] 

Gary Gregory commented on HTTPCORE-544:
---

{quote}I do not know what exactly you are trying to accomplish but In my 
opinion socket timeout does not belong to EndpointDetails.
{quote}
The big picture is that our server, which is designed to stay up for a long 
time and have all of its guts reconfigurable needs to do a lot of logging and 
one of the issues users have sometimes is around timeout issues while, for 
example, passing traffic to other origin servers. So for certain log entries, 
we need to say "request R to origin server O is en route with a N second 
timeout" and "request so and so from client 1.2.3.4 is being processed under a 
N second timeout."

So where can I get the current connection's timeout (from a client or to an 
origin server) from an HttpRequest and HttpContext, for example, when you 
implement 
{{org.apache.hc.core5.http.nio.AsyncServerExchangeHandler.handleRequest(HttpRequest,
 EntityDetails, ResponseChannel, HttpContext)}}?

Thank you,
 Gary

> Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()
> ---
>
> Key: HTTPCORE-544
> URL: https://issues.apache.org/jira/browse/HTTPCORE-544
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add {{org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-544) Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558614#comment-16558614
 ] 

Gary Gregory commented on HTTPCORE-544:
---

Right, so the question becomes: What is the lifecycle of an EndpointDetails 
object? Right now, the TO is _copied_ from either a Socket or an IOSession.

In the case of a Socket: 
[https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;a=blobdiff;f=httpcore5/src/main/java/org/apache/hc/core5/http/impl/io/BHttpConnectionBase.java;h=17f70574eddbe00abc25f604cb92942ad818b0db;hp=94223fd1c31a3fed48d02b4aaa3849674a14c049;hb=9059928;hpb=04f7eb616e70665d58b3ece152be0990cf606d58]

The TO comes from the Socket.

The Socket comes from the SocketHolder.

The SocketHolder comes from an AtomicReference in BHttpConnectionBase.

Setting the socket timeout on a BHttpConnectionBase works all the work from the 
AtomicReference to the actual Socket.

So the EndpointDetail could hold on to the AtomicReference instead of the int. 
The getter in EndpointDetail would go all the de-referencing.

In the case of an IOSession: 

- 
[https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;a=blobdiff;f=httpcore5-h2/src/main/java/org/apache/hc/core5/http2/impl/nio/AbstractHttp2StreamMultiplexer.java;h=59c03a33bdd4aa287b3a2e1ae00100ba80ed5d64;hp=f17e3a84cbf9fdc3e15221d1fbb1a073f360dcc5;hb=9059928;hpb=04f7eb616e70665d58b3ece152be0990cf606d58]

- 
[https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;a=blobdiff;f=httpcore5/src/main/java/org/apache/hc/core5/http/impl/nio/AbstractHttp1StreamDuplexer.java;h=9cd76b642621d21af322cc2f255c021ae428794c;hp=4e3686a5ab1dbcc59dad5bf83c262c11c7114d04;hb=9059928;hpb=04f7eb616e70665d58b3ece152be0990cf606d58]

This is more tricky but we can assume that the value can change since this 
interface has both a getter and setter.

As above, the EndpointDetail could hold on to an IOSession and the ED getter 
could just delegate to the IOSession. But then we might have an ED track both 
an IOSession and AtomicRef to a SocketHolder, which would be ugly.

The same question applies: Can the Socket TO change _during_ the lifetime of an 
Endpoint detail. This I do not know. Do you?

 

> Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()
> ---
>
> Key: HTTPCORE-544
> URL: https://issues.apache.org/jira/browse/HTTPCORE-544
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add {{org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-544) Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-544.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3

In git master.

> Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()
> ---
>
> Key: HTTPCORE-544
> URL: https://issues.apache.org/jira/browse/HTTPCORE-544
> Project: HttpComponents HttpCore
>  Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add {{org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-544) Add org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-544:
-

 Summary: Add 
org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()
 Key: HTTPCORE-544
 URL: https://issues.apache.org/jira/browse/HTTPCORE-544
 Project: HttpComponents HttpCore
  Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory


Add {{org.apache.hc.core5.http.EndpointDetails.getSocketTimeout()}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCORE-543) Update API for HttpRequest and HttpResponse to be fluent

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCORE-543:
--
Description: 
Update API for HttpRequest and HttpResponse to be fluent.

WIP is branch {{dev/5.0.x/HTTPCORE-543}}

 

  was:Update API for HttpRequest and HttpResponse to be fluent.


> Update API for HttpRequest and HttpResponse to be fluent
> 
>
> Key: HTTPCORE-543
> URL: https://issues.apache.org/jira/browse/HTTPCORE-543
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: Gary Gregory
>Priority: Major
>
> Update API for HttpRequest and HttpResponse to be fluent.
> WIP is branch {{dev/5.0.x/HTTPCORE-543}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-543) Update API for HttpRequest and HttpResponse to be fluent

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-543:
-

 Summary: Update API for HttpRequest and HttpResponse to be fluent
 Key: HTTPCORE-543
 URL: https://issues.apache.org/jira/browse/HTTPCORE-543
 Project: HttpComponents HttpCore
  Issue Type: Improvement
  Components: HttpCore
Reporter: Gary Gregory


Update API for HttpRequest and HttpResponse to be fluent.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-542) Add missing org.apache.hc.core5.http.message.BasicClassicHttpRequest.serialVersionUID

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-542.
-
Resolution: Fixed

In git master.

> Add missing 
> org.apache.hc.core5.http.message.BasicClassicHttpRequest.serialVersionUID
> -
>
> Key: HTTPCORE-542
> URL: https://issues.apache.org/jira/browse/HTTPCORE-542
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add missing 
> {{org.apache.hc.core5.http.message.BasicClassicHttpRequest.serialVersionUID}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-542) Add missing org.apache.hc.core5.http.message.BasicClassicHttpRequest.serialVersionUID

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-542:
-

 Summary: Add missing 
org.apache.hc.core5.http.message.BasicClassicHttpRequest.serialVersionUID
 Key: HTTPCORE-542
 URL: https://issues.apache.org/jira/browse/HTTPCORE-542
 Project: HttpComponents HttpCore
  Issue Type: Bug
  Components: HttpCore
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 5.0-beta3


Add missing 
{{org.apache.hc.core5.http.message.BasicClassicHttpRequest.serialVersionUID}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-541) Add HttpVersion.ALL for all HTTP versions known to HttpCore.

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-541.
-
Resolution: Fixed

In git master.

> Add HttpVersion.ALL for all HTTP versions known to HttpCore.
> 
>
> Key: HTTPCORE-541
> URL: https://issues.apache.org/jira/browse/HTTPCORE-541
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> Add HttpVersion.ALL for all HTTP versions known to HttpCore:
> {code:java}
>     /**
>  * All HTTP versions known to HttpCore.
>  */
>     public static final HttpVersion[] ALL = \{HTTP_0_9, HTTP_1_0, HTTP_1_1, 
> HTTP_2_0};
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-541) Add HttpVersion.ALL for all HTTP versions known to HttpCore.

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-541:
-

 Summary: Add HttpVersion.ALL for all HTTP versions known to 
HttpCore.
 Key: HTTPCORE-541
 URL: https://issues.apache.org/jira/browse/HTTPCORE-541
 Project: HttpComponents HttpCore
  Issue Type: Bug
  Components: HttpCore
Reporter: Gary Gregory
 Fix For: 5.0-beta3


Add HttpVersion.ALL for all HTTP versions known to HttpCore:

{code:java}
    /**
 * All HTTP versions known to HttpCore.
 */
    public static final HttpVersion[] ALL = \{HTTP_0_9, HTTP_1_0, HTTP_1_1, 
HTTP_2_0};
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-540) EndpointDetails implements HttpConnectionMetrics

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-540.
-
   Resolution: Fixed
Fix Version/s: 5.0-beta3

In git master.

> EndpointDetails implements HttpConnectionMetrics
> 
>
> Key: HTTPCORE-540
> URL: https://issues.apache.org/jira/browse/HTTPCORE-540
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> {{EndpointDetails}} implements {{HttpConnectionMetrics}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-540) EndpointDetails implements HttpConnectionMetrics

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-540:
-

 Summary: EndpointDetails implements HttpConnectionMetrics
 Key: HTTPCORE-540
 URL: https://issues.apache.org/jira/browse/HTTPCORE-540
 Project: HttpComponents HttpCore
  Issue Type: Bug
  Components: HttpCore
Reporter: Gary Gregory
Assignee: Gary Gregory


{{EndpointDetails}} implements {{HttpConnectionMetrics}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-539) Constructing a new FileEntityProducer for a file whose length is greater than 2GB throws an IllegalArgumentException

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-539.
-
Resolution: Fixed

In git master.

> Constructing a new FileEntityProducer for a file whose length is greater than 
> 2GB throws an IllegalArgumentException
> 
>
> Key: HTTPCORE-539
> URL: https://issues.apache.org/jira/browse/HTTPCORE-539
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Affects Versions: 5.0-beta2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Critical
> Fix For: 5.0-beta3
>
>
> Constructing a new {{FileEntityProducer}} for a file whose length is greater 
> than 2GB throws an {{IllegalArgumentException}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-539) Constructing a new FileEntityProducer for a file whose length is greater than 2GB throws an IllegalArgumentException

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-539:
-

 Summary: Constructing a new FileEntityProducer for a file whose 
length is greater than 2GB throws an IllegalArgumentException
 Key: HTTPCORE-539
 URL: https://issues.apache.org/jira/browse/HTTPCORE-539
 Project: HttpComponents HttpCore
  Issue Type: Improvement
Affects Versions: 5.0-beta2
Reporter: Gary Gregory
 Fix For: 5.0-beta3


Constructing a new {{FileEntityProducer}} for a file whose length is greater 
than 2GB throws an {{IllegalArgumentException}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Assigned] (HTTPCORE-539) Constructing a new FileEntityProducer for a file whose length is greater than 2GB throws an IllegalArgumentException

[Gary Gregory (JIRA)]

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

Gary Gregory reassigned HTTPCORE-539:
-

Assignee: Gary Gregory

> Constructing a new FileEntityProducer for a file whose length is greater than 
> 2GB throws an IllegalArgumentException
> 
>
> Key: HTTPCORE-539
> URL: https://issues.apache.org/jira/browse/HTTPCORE-539
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Affects Versions: 5.0-beta2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Critical
> Fix For: 5.0-beta3
>
>
> Constructing a new {{FileEntityProducer}} for a file whose length is greater 
> than 2GB throws an {{IllegalArgumentException}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1932) Add factory enum org.apache.hc.client5.http.async.methods.HttpRequests

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCLIENT-1932.

Resolution: Fixed

In git master.

> Add factory enum org.apache.hc.client5.http.async.methods.HttpRequests
> --
>
> Key: HTTPCLIENT-1932
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1932
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Add factory enum {{org.apache.hc.client5.http.async.methods.HttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCLIENT-1931) Add factory enum org.apache.hc.client5.http.classic.methods.ClassicHttpRequests

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCLIENT-1931.

Resolution: Fixed

In git master.

> Add factory enum 
> org.apache.hc.client5.http.classic.methods.ClassicHttpRequests
> ---
>
> Key: HTTPCLIENT-1931
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1931
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Add factory enum 
> {{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1932) Add factory enum org.apache.hc.client5.http.async.methods.HttpRequests

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCLIENT-1932:
-
Summary: Add factory enum 
org.apache.hc.client5.http.async.methods.HttpRequests  (was: Add factory enum 
org.apache.hc.client5.http.classic.methods.HttpRequests)

> Add factory enum org.apache.hc.client5.http.async.methods.HttpRequests
> --
>
> Key: HTTPCLIENT-1932
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1932
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Add factory enum 
> {{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1932) Add factory enum org.apache.hc.client5.http.async.methods.HttpRequests

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCLIENT-1932:
-
Description: Add factory enum 
{{org.apache.hc.client5.http.async.methods.HttpRequests}}.  (was: Add factory 
enum {{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.)

> Add factory enum org.apache.hc.client5.http.async.methods.HttpRequests
> --
>
> Key: HTTPCLIENT-1932
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1932
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Add factory enum {{org.apache.hc.client5.http.async.methods.HttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1932) Add factory enum org.apache.hc.client5.http.classic.methods.HttpRequests

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCLIENT-1932:
-
Fix Version/s: (was: 4.5.7)

> Add factory enum org.apache.hc.client5.http.classic.methods.HttpRequests
> 
>
> Key: HTTPCLIENT-1932
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1932
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Add factory enum 
> {{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1931) Add factory enum org.apache.hc.client5.http.classic.methods.ClassicHttpRequests

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCLIENT-1931:
-
Fix Version/s: (was: 4.5.7)

> Add factory enum 
> org.apache.hc.client5.http.classic.methods.ClassicHttpRequests
> ---
>
> Key: HTTPCLIENT-1931
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1931
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> Add factory enum 
> {{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCLIENT-1932) Add factory enum org.apache.hc.client5.http.classic.methods.HttpRequests

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCLIENT-1932:
-
Summary: Add factory enum 
org.apache.hc.client5.http.classic.methods.HttpRequests  (was: CLONE - Add 
factory enum org.apache.hc.client5.http.classic.methods.HttpRequests)

> Add factory enum org.apache.hc.client5.http.classic.methods.HttpRequests
> 
>
> Key: HTTPCLIENT-1932
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1932
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.5.7, 5.0 Beta2
>
>
> Add factory enum 
> {{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1932) CLONE - Add factory enum org.apache.hc.client5.http.classic.methods.HttpRequests

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCLIENT-1932:


 Summary: CLONE - Add factory enum 
org.apache.hc.client5.http.classic.methods.HttpRequests
 Key: HTTPCLIENT-1932
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1932
 Project: HttpComponents HttpClient
  Issue Type: Improvement
  Components: HttpClient (classic)
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 4.5.7, 5.0 Beta2


Add factory enum 
{{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCLIENT-1931) Add factory enum org.apache.hc.client5.http.classic.methods.ClassicHttpRequests

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCLIENT-1931:


 Summary: Add factory enum 
org.apache.hc.client5.http.classic.methods.ClassicHttpRequests
 Key: HTTPCLIENT-1931
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1931
 Project: HttpComponents HttpClient
  Issue Type: Improvement
  Components: HttpClient (classic)
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 4.5.7, 5.0 Beta2


Add factory enum 
{{org.apache.hc.client5.http.classic.methods.ClassicHttpRequests}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Closed] (HTTPCORE-537) org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code twice and no protocol version.

[Gary Gregory (JIRA)]

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

Gary Gregory closed HTTPCORE-537.
-
Resolution: Fixed
  Assignee: Gary Gregory

In git master.

> org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code 
> twice and no protocol version.
> 
>
> Key: HTTPCORE-537
> URL: https://issues.apache.org/jira/browse/HTTPCORE-537
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.0-beta2
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code 
> twice and no protocol version. The result should be "  
> "



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Updated] (HTTPCORE-537) org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code twice and no protocol version.

[Gary Gregory (JIRA)]

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

Gary Gregory updated HTTPCORE-537:
--
Description: org.apache.hc.core5.http.message.BasicHttpResponse.toString() 
prints its code twice and no protocol version. The result should be " 
 "  (was: 
org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code 
twice and no protocol version.)

> org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code 
> twice and no protocol version.
> 
>
> Key: HTTPCORE-537
> URL: https://issues.apache.org/jira/browse/HTTPCORE-537
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.0-beta2
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 5.0-beta3
>
>
> org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code 
> twice and no protocol version. The result should be "  
> "



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-537) org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code twice and no protocol version.

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-537:
-

 Summary: 
org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code 
twice and no protocol version.
 Key: HTTPCORE-537
 URL: https://issues.apache.org/jira/browse/HTTPCORE-537
 Project: HttpComponents HttpCore
  Issue Type: Improvement
  Components: HttpCore
Affects Versions: 5.0-beta2
Reporter: Gary Gregory
 Fix For: 5.0-beta3


org.apache.hc.core5.http.message.BasicHttpResponse.toString() prints its code 
twice and no protocol version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Resolved] (HTTPCORE-527) Add remote address when throwing a ConnectException

[Gary Gregory (JIRA)]

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

Gary Gregory resolved HTTPCORE-527.
---
   Resolution: Fixed
Fix Version/s: 4.4.10

Committed to branch {{4.4.x}}.

> Add remote address when throwing a ConnectException
> ---
>
> Key: HTTPCORE-527
> URL: https://issues.apache.org/jira/browse/HTTPCORE-527
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 4.4.10
>
>
> PR: https://github.com/apache/httpcomponents-core/pull/64



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Created] (HTTPCORE-527) Add remote address when throwing a ConnectException

[Gary Gregory (JIRA)]

Gary Gregory created HTTPCORE-527:
-

 Summary: Add remote address when throwing a ConnectException
 Key: HTTPCORE-527
 URL: https://issues.apache.org/jira/browse/HTTPCORE-527
 Project: HttpComponents HttpCore
  Issue Type: Improvement
Reporter: Gary Gregory
Assignee: Gary Gregory


PR: https://github.com/apache/httpcomponents-core/pull/64



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1922) org.apache.http.wire package is printing sensitive information in debug

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470459#comment-16470459
 ] 

Gary Gregory commented on HTTPCLIENT-1922:
--

If you use Log4j 2, you can filter your log output, for example: 
https://logging.apache.org/log4j/2.x/manual/filters.html#RegexFilter

> org.apache.http.wire package is printing sensitive information in debug
> ---
>
> Key: HTTPCLIENT-1922
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1922
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (Windows)
> Environment: Windows, linux
>Reporter: Vijay Jamadade
>Priority: Minor
>
> Hi,
> We are using httpclient-4.3.6.jar for connecting to web service. Data being 
> sent for authentication is sensitive data containing private keys used for 
> authentication. But when i enable debug level logging for my connection, 
> org.apache.http.wire is this jar prints this sensitive information in log. 
> How can I disable this? Is this known issue? 
> This can be major security issue as somebody can easily get sensitive 
> information in logs this way.
> Thanks,
> Vijay



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCLIENT-1916) Add method removeParameter to URIBuilder

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16446011#comment-16446011
 ] 

Gary Gregory commented on HTTPCLIENT-1916:
--

With unit tests of course ;)

> Add method removeParameter to URIBuilder
> 
>
> Key: HTTPCLIENT-1916
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1916
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (classic)
>Affects Versions: 4.5.5, 4.5.6, 5.0 Beta1, 5.0 Beta2
>Reporter: Jorge Moraleda
>Priority: Trivial
>  Labels: features
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> It would be convenient to have a *removeParameter* method added to class 
> *URIBuilder*.
> One rationale for this proposal is the use case when of reusing an 
> *URIBuilder* to create multiple similar HMAC signed requests. In that 
> scenario it is not sufficient to invoke *setParameter* with the values of the 
> parameters that have changed. One also needs to remove the _signature_ 
> parameter from the previous request before the current request can be signed 
> and a new _signature_ parameter added to it.
> This would be the implementation of the proposed method *removeParameter*:
> {code:java}
> /**
>  * Remove parameter of URI query if set. The parameter name is expected 
> to be unescaped and 
>  * may contain non ASCII characters.
>  * 
>  * Please note query parameters and custom query component are mutually 
> exclusive. This method
>  * will remove custom query if present.
>  * 
>  */
> public URIBuilder removeParameter(final String param) {
> if (this.queryParams == null) {
> return this;
> }
> if (!this.queryParams.isEmpty()) {
> for (final Iterator it = 
> this.queryParams.iterator(); it.hasNext(); ) {
> final NameValuePair nvp = it.next();
> if (nvp.getName().equals(param)) {
> it.remove();
> }
> }
> }
> this.encodedQuery = null;
> this.encodedSchemeSpecificPart = null;
> this.query = null;
> return this;
>}
> {code}
> Since the proposed implementation above is the current implementation of 
> *setParameter* minus the one line that actually adds the new parameter, then 
> the implementation of *setParameter* could be simplified greatly to:
>  
> {code:java}
> /**
>  * Sets parameter of URI query overriding existing value if set. The 
> parameter name and value
>  * are expected to be unescaped and may contain non ASCII characters.
>  * 
>  * Please note query parameters and custom query component are mutually 
> exclusive. This method
>  * will remove custom query if present.
>  * 
>  */
> public URIBuilder setParameter(final String param, final String value) {
> removeParameter(param);
> if (this.queryParams == null) {
> this.queryParams = new ArrayList();
> }
> this.queryParams.add(new BasicNameValuePair(param, value));
> return this;
> }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Comment Edited] (HTTPCORE-519) Failing tests on Fedora 28 due to weak encryption algorithms in test keystore

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417375#comment-16417375
 ] 

Gary Gregory edited comment on HTTPCORE-519 at 3/28/18 2:04 PM:


I've stopped for now. Please go ahead.


was (Author: garydgregory):
I've stopped for now.

> Failing tests on Fedora 28 due to weak encryption algorithms in test keystore
> -
>
> Key: HTTPCORE-519
> URL: https://issues.apache.org/jira/browse/HTTPCORE-519
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 4.4.9
>Reporter: Michael Simacek
>Priority: Major
> Fix For: 4.4.10
>
>
> Fedora Linux from release 28 (not released yet) deprecates usage of insecure 
> encryption algorithms by default 
> ([docs|https://fedoraproject.org/wiki/Changes/StrongCryptoSettings]). This 
> causes httpcomponents tests to fail, because they're using DSA keys in the 
> test data.
> The affected tests are:
> TestCustomSSL.testCustomSSLContext
> TestHttpAsyncHandlers.testHttpExceptionInHandler
> TestHttpAsyncHandlers.testHttpGets
> TestHttpAsyncHandlers.testHttpHeadsDelayedResponse
> TestHttpAsyncHandlers.testHttpHeads
> TestHttpAsyncHandlers.testHttpPostIdentity
> TestHttpAsyncHandlers.testHttpPostNoContentLength
> TestHttpAsyncHandlers.testHttpPostsChunked
> TestHttpAsyncHandlers.testHttpPostsHTTP10
> TestHttpAsyncHandlers.testHttpPostsNoEntity
> TestHttpAsyncHandlers.testHttpPostsWithContentLength
> TestHttpAsyncHandlers.testHttpPostsWithExpectContinue
> TestHttpAsyncHandlers.testHttpPostsWithExpectationVerificationDelayedResponse
> TestHttpAsyncHandlers.testHttpPostsWithExpectationVerification
> TestHttpAsyncHandlers.testNoServiceHandler
> TestHttpAsyncHandlers.testResponseNoContent
> TestHttpAsyncHandlersPipelining.testHttpDelayedResponse
> TestHttpAsyncHandlersPipelining.testHttpGets
> TestHttpAsyncHandlersPipelining.testHttpHeads
> TestHttpAsyncHandlersPipelining.testHttpPosts
> TestHttpAsyncHandlersPipelining.testUnexpectedConnectionClosure



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPCORE-519) Failing tests on Fedora 28 due to weak encryption algorithms in test keystore

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPCORE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417375#comment-16417375
 ] 

Gary Gregory commented on HTTPCORE-519:
---

I've stopped for now.

> Failing tests on Fedora 28 due to weak encryption algorithms in test keystore
> -
>
> Key: HTTPCORE-519
> URL: https://issues.apache.org/jira/browse/HTTPCORE-519
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 4.4.9
>Reporter: Michael Simacek
>Priority: Major
> Fix For: 4.4.10
>
>
> Fedora Linux from release 28 (not released yet) deprecates usage of insecure 
> encryption algorithms by default 
> ([docs|https://fedoraproject.org/wiki/Changes/StrongCryptoSettings]). This 
> causes httpcomponents tests to fail, because they're using DSA keys in the 
> test data.
> The affected tests are:
> TestCustomSSL.testCustomSSLContext
> TestHttpAsyncHandlers.testHttpExceptionInHandler
> TestHttpAsyncHandlers.testHttpGets
> TestHttpAsyncHandlers.testHttpHeadsDelayedResponse
> TestHttpAsyncHandlers.testHttpHeads
> TestHttpAsyncHandlers.testHttpPostIdentity
> TestHttpAsyncHandlers.testHttpPostNoContentLength
> TestHttpAsyncHandlers.testHttpPostsChunked
> TestHttpAsyncHandlers.testHttpPostsHTTP10
> TestHttpAsyncHandlers.testHttpPostsNoEntity
> TestHttpAsyncHandlers.testHttpPostsWithContentLength
> TestHttpAsyncHandlers.testHttpPostsWithExpectContinue
> TestHttpAsyncHandlers.testHttpPostsWithExpectationVerificationDelayedResponse
> TestHttpAsyncHandlers.testHttpPostsWithExpectationVerification
> TestHttpAsyncHandlers.testNoServiceHandler
> TestHttpAsyncHandlers.testResponseNoContent
> TestHttpAsyncHandlersPipelining.testHttpDelayedResponse
> TestHttpAsyncHandlersPipelining.testHttpGets
> TestHttpAsyncHandlersPipelining.testHttpHeads
> TestHttpAsyncHandlersPipelining.testHttpPosts
> TestHttpAsyncHandlersPipelining.testUnexpectedConnectionClosure



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Commented] (HTTPASYNC-135) HttpAsyncMethods.createHead() methods creates HttpGet objects

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/HTTPASYNC-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409765#comment-16409765
 ] 

Gary Gregory commented on HTTPASYNC-135:


Why don't you just check out the code?

> HttpAsyncMethods.createHead() methods creates HttpGet objects
> -
>
> Key: HTTPASYNC-135
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-135
> Project: HttpComponents HttpAsyncClient
>  Issue Type: Bug
>Affects Versions: 4.1.2, 4.1.3
>Reporter: Mateusz Matela
>Priority: Trivial
> Fix For: 4.1.4
>
>
> Looking at {{org.apache.http.nio.client.methods.HttpAsyncMethods}}, the 
> {{createHead}} method works exactly the same as {{createGet}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org