[jira] [Commented] (HTTPCLIENT-2327) MemcachedHttpAsyncCacheStorage propagates CancellationException from cancelled cache requests to caller
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846954#comment-17846954
]
ASF subversion and git services commented on HTTPCLIENT-2327:
-
Commit 0f37ebdc7d3182f78c3b0d3ea19c1bbedf792ad2 in httpcomponents-client's
branch refs/heads/master from jattisha
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=0f37ebdc7 ]
HTTPCLIENT-2327: Propagate CancellationExceptions from MemcachedClient
operations as ResourceIOExceptions (#559)
> MemcachedHttpAsyncCacheStorage propagates CancellationException from
> cancelled cache requests to caller
> ---
>
> Key: HTTPCLIENT-2327
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2327
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCache
>Reporter: Jovan Attisha
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Spymemcached provides options to handle failure modes when an in-flight
> request to a Memcached instance fails (for example, when deploying to a
> Memcached server that is currently serving requests). One of the modes, and
> the most logical for our scenario in particular, is
> [Cancel|https://github.com/couchbase/spymemcached/blob/master/src/main/java/net/spy/memcached/FailureMode.java#L51-L54].
> This, as you would expect, cancels any futures that are in-flight when a
> Memcached node becomes unreachable.
>
> The issue that we're having is that the
> {{[MemcachedHttpAsyncCacheStorage|https://github.com/apache/httpcomponents-client/blob/master/httpclient5-cache/src/main/java/org/apache/hc/client5/http/impl/cache/memcached/MemcachedHttpAsyncCacheStorage.java#L184]}}
> (for restore linked here, as this is our issue, but also for other methods),
> doesn't handle the {{CancellationException}} gracefully, and instead
> propagates this Exception up to the caller. Since this is a cache for an HTTP
> client, I would expect the client to handle the cancellation as a "cache
> miss" (I would almost expect this behavior for {_}all exceptions{_}, though
> I'm likely not thinking of some edge cases here) and proceed to make the
> request to the resource originally requested, since the cache is a mere
> optimization, and a failure in the cache should not impact the actual request
> to the resource we're targeting.
>
> We did POC this by extending the
> {{[MemcachedHttpAsyncCacheStorage|https://github.com/apache/httpcomponents-client/blob/master/httpclient5-cache/src/main/java/org/apache/hc/client5/http/impl/cache/memcached/MemcachedHttpAsyncCacheStorage.java#L184]}}
> and overriding the {{restore}} method to explicitly handle
> {{{}CancellationException{}}}s and complete the future to treat it as a cache
> miss, but before we proceed with this, we want to understand if:
> 1. The Apache HTTPClient agrees that this is the desired behavior
> 2. If so, would the Apache HTTP Client accept this behavior in the client
> itself, rather than us extending to override this behavior
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2325) Avoid adding "; charset=" for multipart/form-data requests
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828069#comment-17828069
]
ASF subversion and git services commented on HTTPCLIENT-2325:
-
Commit 3b9bc89c2604c4e4ad509fb922e6c88ff101e13e in httpcomponents-client's
branch refs/heads/master from Vladimir Sitnikov
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=3b9bc89c2 ]
HTTPCLIENT-2325 Avoid adding "; charset=" for multipart/form-data requests
Previusly, "charset" parameter was added to the Content-Type header, however
adding "charset=..."
is not specified in RFC 7578, and it causes issues with (flawed?) HTTP servers.
The change does not modify ContentType.MULTIPART_FORM_DATA, and it might have
backward compatibility
side-effects.
See
* https://github.com/apache/jmeter/issues/6250
*
https://github.com/owasp-modsecurity/ModSecurity/commit/6e56950cdf258c9b39f12cf6eb014cb59797cfd3
* https://bz.apache.org/bugzilla/show_bug.cgi?id=61384
* https://github.com/akka/akka-http/issues/338
> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which
> both
> 1) Breaks certain HTTP servers: see
> https://github.com/apache/jmeter/pull/6251,
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by
> RFCs, there are known HTTP servers that can't parse such requests, so why
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset:
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
>
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in
> the caller's code is not enough as HttpClient uses the supplied charset in
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header,
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines:
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2319) DateUtils.parseStandardDate() throws exception instead of returning null
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820155#comment-17820155
]
ASF subversion and git services commented on HTTPCLIENT-2319:
-
Commit f2b9a374d817ee630a2efe706546ba4f1e5a5ac4 in httpcomponents-client's
branch refs/heads/master from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=f2b9a374d ]
HTTPCLIENT-2319 / Updated the parseDate method to solely catch
DateTimeException, streamlining error handling for date parsing and conversion.
This change ensures comprehensive management of parsing issues, including those
due to absent time-zone information, aligning with our documentation that the
method should return null when conversion to Instant is not feasible. (#551)
> DateUtils.parseStandardDate() throws exception instead of returning null
>
>
> Key: HTTPCLIENT-2319
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2319
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.3.1
>Reporter: Bernd Watermann
>Priority: Minor
>
> The following line of code
> {code:java}
> org.apache.hc.client5.http.utils.DateUtils.parseStandardDate("Thu Feb 22
> 17:20:18 2024");{code}
> throws an exception with the following stack trace:
> {noformat}
> java.time.DateTimeException: Unable to obtain Instant from TemporalAccessor:
> {},ISO resolved to 2024-02-22T17:20:18 of type java.time.format.Parsed
> at java.base/java.time.Instant.from(Instant.java:380)
> at
> org.apache.hc.client5.http.utils.DateUtils.parseDate(DateUtils.java:165)
> at
> org.apache.hc.client5.http.utils.DateUtils.parseStandardDate(DateUtils.java:183){noformat}
> The documentation for parseStandardDate(), however, says:
> ??Returns: the parsed instant or null if input could not be parsed??
> Throwing an exception does not seem to conform to that spec.
> Note that I don't care (at present) if the given string should actually be
> parseable or not. The primary issue is error handling and the fact that any
> error should lead to a null result and not to an exception being thrown.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2318) Implement HttpClientConnectionManager#isShutdown
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820065#comment-17820065 ] ASF subversion and git services commented on HTTPCLIENT-2318: - Commit 407b9152ccafa120ce9e9cd14325c3cc78eb20c1 in httpcomponents-client's branch refs/heads/master from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=407b9152c ] HTTPCLIENT-2318 - Enhance PoolingHttpClientConnectionManager with isShutdown State Check. This commit introduces an `isShutdown` method to the `PoolingHttpClientConnectionManager` class, providing a thread-safe way to check whether the connection manager has been closed. The addition leverages an existing `AtomicBoolean` closed flag to ensure that the shutdown state can be queried reliably in concurrent environments. > Implement HttpClientConnectionManager#isShutdown > > > Key: HTTPCLIENT-2318 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2318 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpClient (classic) >Reporter: Edmund Ham >Assignee: Arturo Bernal >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Hi all, > We have an internal library that has core logics and lots of microservices > are using it. Within the internal library, we have "HttpClientPool" where we > are caching different HttpClient based on keys and microservices are using > them. Recently, we've been seeing some of OOM errors on microservices when > using HttpClients from our "HttpClientPool". > From https://issues.apache.org/jira/browse/HTTPCLIENT-2039 and > https://issues.apache.org/jira/browse/HTTPCLIENT-1924 we understand that it > is the intention to shutdown the connection pool in case of Java Errors. I'm > now wondering if it's possible to have new API, > "HttpClientConnectionManager#isShutdown" so that we as a library can identify > if the connection pool is closed or not, before giving out to our clients? > Currently there seems to be no way to identify it, unless we actually try to > make an outbound call and get "IllegalStateException: Connection pool shut > down" exception message, which makes impossible for us to do because we as a > library don't want to make additional HTTP client call every time when our > client requests for the HttpClient instance. > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2151) Optionally use JSSE inbuilt endpoint identification
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814287#comment-17814287
]
ASF subversion and git services commented on HTTPCLIENT-2151:
-
Commit 2e46b62ffd8c0e00ac7438c6c81b9ac6ec445149 in httpcomponents-client's
branch refs/heads/master from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=2e46b62ff ]
HTTPCLIENT-2151: Support for JSSE in-built endpoint identification
> Optionally use JSSE inbuilt endpoint identification
> ---
>
> Key: HTTPCLIENT-2151
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2151
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient (classic)
>Reporter: Peter Dettman
>Priority: Minor
> Fix For: 5.4-alpha2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This issue brings to the fore that part of HTTPCLIENT-2134 which is actually
> within the scope of HttpClient: the possibility of using JSSE inbuilt
> endpoint identification ("HTTPS") instead of performing those checks
> externally (typically in
> _org.apache.hc.client5.http.ssl.DefaultHostnameVerifier_).
> Java 1.7 added the method
> SSLParameters.setEndpointIdentificationAlgorithm(String). Calling this method
> with the argument "HTTPS" (case-insensitive) will result in the endpoint
> identification checks from RFC 2818 being automatically done by JSSE during
> the handshake (specifically when the X509TrustManager validates the server
> certificate). Note that the setting can also be interrogated via
> SSLParameters.getEndpointIdentificationAlgorithm.
> This has some minor advantages relative to performing the checks externally:
> * The check is done earlier in the handshake, reducing the cost of failed
> connections. (Technically this might still be achieved anyway by wrapping the
> X509TrustManager and applying a HostnameVerifier at that stage).
> * Per my comments in HTTPCLIENT-2134, in some nuanced situations SunJSSE will
> be willing to resume a session only if it knows for sure that endpoint
> identification is being used (which it can't know for an arbitrary
> HostnameVerifier).
> * SunJSSE's HTTPS endpoint identification has special (less-restrictive)
> rules for wildcard characters when the trust anchor is a certificate from the
> 'cacerts' file (what it calls a "public root CA").
> There may be other implications that I am unaware of, but I think this
> establishes that some users may prefer (or even need) to delegate endpoint
> identification to JSSE in this way. They presumably will not then want a
> duplicate check in DefaultHostnameVerifier.
> I am not yet that familiar with HttpClient, but I assume a user could already
> provide a custom SSLSocketFactory which enables JSSE endpoint identification
> on sockets before returning them, and then separately configure a no-op
> HostnameVerifier. I consider that to be rather fragile and it's easy to see
> mistakes leading to no endpoint identification being performed.
> I am proposing that HttpClient support this via a simpler configuration
> mechanism. To loosely outline some basic options:
> IGNORE: don't even check whether JSSE endpoint identification was enabled
> (i.e. assume it wasn't).
> AWARE: check at runtime whether JSSE endpoint identification was "HTTPS" for
> a given socket connection.
> DISABLE: remove any existing setting for JSSE endpoint identification (set it
> to "").
> FORCE: overwrite any existing setting for JSSE endpoint identification (set
> it to "HTTPS").
> So we would consider some value that came to us via the SSLSocketFactory's
> default socket setup, and whether to ignore it, respect it, or force it
> on/off. DefaultHostnameVerifier can then be set to possibly skip its own
> endpoint checks when appropriate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2316) ConnectionShutdownException when connection is closed for 401 response
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812655#comment-17812655
]
ASF subversion and git services commented on HTTPCLIENT-2316:
-
Commit fa8ca22d2106decdc938baef5bfbe9505c72c075 in httpcomponents-client's
branch refs/heads/master from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=fa8ca22d2 ]
HTTPCLIENT-2316: BasicHttpClientConnectionManager incorrectly re-uses the
released connection if it has been closed out by the protocol handler
> ConnectionShutdownException when connection is closed for 401 response
> --
>
> Key: HTTPCLIENT-2316
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2316
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.3.1
> Environment: Ubuntu Linux, Java 17.0.10, connecting to an Apache Web
> Server
>Reporter: Stephan Windmüller
>Priority: Major
> Attachments: log-output-38d8d9b.txt, log-output-8266a9c.txt,
> log-output.txt
>
>
> When a connection is used for multiple requests, the {{Keep-Alive}} header
> has a {{max}} value that is reduced until it reaches 0, resulting in a
> {{Connection: closed}} header. If that happens while a 401 response is
> handled, the following code is executed:
> {code:java}
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.markConnectionNonReusable(InternalExecRuntime.java:233)
> at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:142)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
> at
> org.apache.hc.client5.http.fluent.Request.internalExecute(Request.java:201)
> at org.apache.hc.client5.http.fluent.Executor.execute(Executor.java:244)
> {code}
> After that,
> {{org.apache.hc.client5.http.impl.classic.InternalExecRuntime#disconnectEndpoint}}
> is called. Any further attempt to use that connection results in this
> stacktrace:
> {code:java}
> org.apache.hc.client5.http.impl.ConnectionShutdownException
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.getConnection(BasicHttpClientConnectionManager.java:502)
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.isConnected(BasicHttpClientConnectionManager.java:519)
> at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.isEndpointConnected(InternalExecRuntime.java:149)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:128)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
>
[jira] [Commented] (HTTPCLIENT-2316) ConnectionShutdownException when connection is closed for 401 response
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812644#comment-17812644
]
ASF subversion and git services commented on HTTPCLIENT-2316:
-
Commit 6792909791facf02e2d0cc4d401613784f4aeb3d in httpcomponents-client's
branch refs/heads/5.3.x from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=679290979 ]
HTTPCLIENT-2316: BasicHttpClientConnectionManager incorrectly re-uses the
released connection if it has been closed out by the protocol handler
> ConnectionShutdownException when connection is closed for 401 response
> --
>
> Key: HTTPCLIENT-2316
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2316
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.3.1
> Environment: Ubuntu Linux, Java 17.0.10, connecting to an Apache Web
> Server
>Reporter: Stephan Windmüller
>Priority: Major
> Attachments: log-output-38d8d9b.txt, log-output-8266a9c.txt,
> log-output.txt
>
>
> When a connection is used for multiple requests, the {{Keep-Alive}} header
> has a {{max}} value that is reduced until it reaches 0, resulting in a
> {{Connection: closed}} header. If that happens while a 401 response is
> handled, the following code is executed:
> {code:java}
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.markConnectionNonReusable(InternalExecRuntime.java:233)
> at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:142)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
> at
> org.apache.hc.client5.http.fluent.Request.internalExecute(Request.java:201)
> at org.apache.hc.client5.http.fluent.Executor.execute(Executor.java:244)
> {code}
> After that,
> {{org.apache.hc.client5.http.impl.classic.InternalExecRuntime#disconnectEndpoint}}
> is called. Any further attempt to use that connection results in this
> stacktrace:
> {code:java}
> org.apache.hc.client5.http.impl.ConnectionShutdownException
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.getConnection(BasicHttpClientConnectionManager.java:502)
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.isConnected(BasicHttpClientConnectionManager.java:519)
> at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.isEndpointConnected(InternalExecRuntime.java:149)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:128)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
>
[jira] [Commented] (HTTPCLIENT-2316) ConnectionShutdownException when connection is closed for 401 response
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812635#comment-17812635
]
ASF subversion and git services commented on HTTPCLIENT-2316:
-
Commit 257e3451dd433e244d9c145aadfb9f1dc65a12a2 in httpcomponents-client's
branch refs/heads/HTTPCLIENT-2316 from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=257e3451d ]
HTTPCLIENT-2316: BasicHttpClientConnectionManager incorrectly re-uses the
released connection if it has been closed out by the protocol handler
> ConnectionShutdownException when connection is closed for 401 response
> --
>
> Key: HTTPCLIENT-2316
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2316
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.3.1
> Environment: Ubuntu Linux, Java 17.0.10, connecting to an Apache Web
> Server
>Reporter: Stephan Windmüller
>Priority: Major
> Attachments: log-output-38d8d9b.txt, log-output-8266a9c.txt,
> log-output.txt
>
>
> When a connection is used for multiple requests, the {{Keep-Alive}} header
> has a {{max}} value that is reduced until it reaches 0, resulting in a
> {{Connection: closed}} header. If that happens while a 401 response is
> handled, the following code is executed:
> {code:java}
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.markConnectionNonReusable(InternalExecRuntime.java:233)
> at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:142)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
> at
> org.apache.hc.client5.http.fluent.Request.internalExecute(Request.java:201)
> at org.apache.hc.client5.http.fluent.Executor.execute(Executor.java:244)
> {code}
> After that,
> {{org.apache.hc.client5.http.impl.classic.InternalExecRuntime#disconnectEndpoint}}
> is called. Any further attempt to use that connection results in this
> stacktrace:
> {code:java}
> org.apache.hc.client5.http.impl.ConnectionShutdownException
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.getConnection(BasicHttpClientConnectionManager.java:502)
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.isConnected(BasicHttpClientConnectionManager.java:519)
> at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.isEndpointConnected(InternalExecRuntime.java:149)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:128)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
>
[jira] [Commented] (HTTPCLIENT-2316) ConnectionShutdownException when connection is closed for 401 response
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812627#comment-17812627
]
ASF subversion and git services commented on HTTPCLIENT-2316:
-
Commit 0856f9d22dbb0d0d6efbb1e239480d6798b75ad6 in httpcomponents-client's
branch refs/heads/HTTPCLIENT-2316 from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=0856f9d22 ]
HTTPCLIENT-2316: BasicHttpClientConnectionManager incorrectly re-uses the
released connection if it has been closed out by the protocol handler
> ConnectionShutdownException when connection is closed for 401 response
> --
>
> Key: HTTPCLIENT-2316
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2316
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.3.1
> Environment: Ubuntu Linux, Java 17.0.10, connecting to an Apache Web
> Server
>Reporter: Stephan Windmüller
>Priority: Major
> Attachments: log-output-38d8d9b.txt, log-output-8266a9c.txt,
> log-output.txt
>
>
> When a connection is used for multiple requests, the {{Keep-Alive}} header
> has a {{max}} value that is reduced until it reaches 0, resulting in a
> {{Connection: closed}} header. If that happens while a 401 response is
> handled, the following code is executed:
> {code:java}
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.markConnectionNonReusable(InternalExecRuntime.java:233)
> at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:142)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
> at
> org.apache.hc.client5.http.fluent.Request.internalExecute(Request.java:201)
> at org.apache.hc.client5.http.fluent.Executor.execute(Executor.java:244)
> {code}
> After that,
> {{org.apache.hc.client5.http.impl.classic.InternalExecRuntime#disconnectEndpoint}}
> is called. Any further attempt to use that connection results in this
> stacktrace:
> {code:java}
> org.apache.hc.client5.http.impl.ConnectionShutdownException
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.getConnection(BasicHttpClientConnectionManager.java:502)
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.isConnected(BasicHttpClientConnectionManager.java:519)
> at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.isEndpointConnected(InternalExecRuntime.java:149)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:128)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
>
[jira] [Commented] (HTTPCLIENT-2070) BasicAuthCache not to use object serialization
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812594#comment-17812594 ] ASF subversion and git services commented on HTTPCLIENT-2070: - Commit 23da984fb5e4f3ecce933c9d3dc8b5e87d06f91a in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=23da984fb ] HTTPCLIENT-2070: Auth cache to no longer rely on Java serialization for auth state caching > BasicAuthCache not to use object serialization > -- > > Key: HTTPCLIENT-2070 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2070 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Alex Dettinger >Priority: Major > Labels: volunteers-wanted > Fix For: 5.4-alpha2 > > Time Spent: 50m > Remaining Estimate: 0h > > Today, BasicAuthCache is using object serialization in [put/get > methods|https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/auth/BasicAuthCache.java#L91..L93]. > However, object serialization is not supported with [quarkus native > mode|https://quarkus.io/guides/building-native-image] and folk ends up > removing this part. > Folks ends up removing serialization by [native code > override|https://github.com/quarkusio/quarkus/blob/master/extensions/elasticsearch-rest-client/runtime/src/main/java/io/quarkus/elasticsearch/restclient/runtime/graal/Substitute_RestClient.java#L93..L114]. > Would it be possible to have httpclient finding an implementation of put/get > not using object serialization ? > What is the consequence of removing the serialization/deserialization ? > Thread safety issue ? persistence issue ? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2316) ConnectionShutdownException when connection is closed for 401 response
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812416#comment-17812416
]
ASF subversion and git services commented on HTTPCLIENT-2316:
-
Commit 8266a9cfb7d2c1411ccfa18d7921e38ea71fe354 in httpcomponents-client's
branch refs/heads/HTTPCLIENT-2316 from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=8266a9cfb ]
HTTPCLIENT-2316: BasicHttpClientConnectionManager incorrectly re-uses the
released connection if it has been closed out by the protocol handler
> ConnectionShutdownException when connection is closed for 401 response
> --
>
> Key: HTTPCLIENT-2316
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2316
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.3.1
> Environment: Ubuntu Linux, Java 17.0.10, connecting to an Apache Web
> Server
>Reporter: Stephan Windmüller
>Priority: Major
> Attachments: log-output-38d8d9b.txt, log-output.txt
>
>
> When a connection is used for multiple requests, the {{Keep-Alive}} header
> has a {{max}} value that is reduced until it reaches 0, resulting in a
> {{Connection: closed}} header. If that happens while a 401 response is
> handled, the following code is executed:
> {code:java}
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.markConnectionNonReusable(InternalExecRuntime.java:233)
> at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:142)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
> at
> org.apache.hc.client5.http.fluent.Request.internalExecute(Request.java:201)
> at org.apache.hc.client5.http.fluent.Executor.execute(Executor.java:244)
> {code}
> After that,
> {{org.apache.hc.client5.http.impl.classic.InternalExecRuntime#disconnectEndpoint}}
> is called. Any further attempt to use that connection results in this
> stacktrace:
> {code:java}
> org.apache.hc.client5.http.impl.ConnectionShutdownException
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.getConnection(BasicHttpClientConnectionManager.java:502)
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.isConnected(BasicHttpClientConnectionManager.java:519)
> at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.isEndpointConnected(InternalExecRuntime.java:149)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:128)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
>
[jira] [Commented] (HTTPCLIENT-2316) ConnectionShutdownException when connection is closed for 401 response
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812387#comment-17812387
]
ASF subversion and git services commented on HTTPCLIENT-2316:
-
Commit 38d8d9b62eb6c6c6e8a47afd88cce4b43dc8d1b2 in httpcomponents-client's
branch refs/heads/HTTPCLIENT-2316 from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=38d8d9b62 ]
HTTPCLIENT-2316: BasicHttpClientConnectionManager incorrectly re-uses the
released connection if it has been closed out by the protocol handler
> ConnectionShutdownException when connection is closed for 401 response
> --
>
> Key: HTTPCLIENT-2316
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2316
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.3.1
> Environment: Ubuntu Linux, Java 17.0.10, connecting to an Apache Web
> Server
>Reporter: Stephan Windmüller
>Priority: Major
> Attachments: log-output.txt
>
>
> When a connection is used for multiple requests, the {{Keep-Alive}} header
> has a {{max}} value that is reduced until it reaches 0, resulting in a
> {{Connection: closed}} header. If that happens while a 401 response is
> handled, the following code is executed:
> {code:java}
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.markConnectionNonReusable(InternalExecRuntime.java:233)
> at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:142)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
> at
> org.apache.hc.client5.http.fluent.Request.internalExecute(Request.java:201)
> at org.apache.hc.client5.http.fluent.Executor.execute(Executor.java:244)
> {code}
> After that,
> {{org.apache.hc.client5.http.impl.classic.InternalExecRuntime#disconnectEndpoint}}
> is called. Any further attempt to use that connection results in this
> stacktrace:
> {code:java}
> org.apache.hc.client5.http.impl.ConnectionShutdownException
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.getConnection(BasicHttpClientConnectionManager.java:502)
> at
> org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager$InternalConnectionEndpoint.isConnected(BasicHttpClientConnectionManager.java:519)
> at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.isEndpointConnected(InternalExecRuntime.java:149)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:128)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> at
[jira] [Commented] (HTTPCLIENT-751) ProtocolSocketFactory to upgrade an unsecured connection to secured via TLS
[ https://issues.apache.org/jira/browse/HTTPCLIENT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811870#comment-17811870 ] ASF subversion and git services commented on HTTPCLIENT-751: Commit 3235f009d5673536be5c668df409ac3f83808d89 in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=3235f009d ] HTTPCLIENT-751: Support for RFC 2817 (Upgrading to TLS Within HTTP/1.1) > ProtocolSocketFactory to upgrade an unsecured connection to secured via TLS > --- > > Key: HTTPCLIENT-751 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-751 > Project: HttpComponents HttpClient > Issue Type: New Feature > Environment: Coded for Java 1.4.2, but interested parties should be > able to make it work for less than that. >Reporter: Stephen O'Neil Butler >Priority: Minor > Fix For: 5.4-alpha2 > > Attachments: TLSProtocolSocketFactory.java > > Time Spent: 50m > Remaining Estimate: 0h > > HTTP allows a client to upgrade its connection from an unsecured one to a > secured one via the Upgrade header. This protocol component implements a > mandatory upgrade. From RFC2817, section 3.2: > >> OPTIONS * HTTP/1.1 > >> Host: example.bank.com > >> Upgrade: TLS/1.0 > >> Connection: Upgrade > >> > << HTTP/1.1 101 Switching Protocols > << Upgrade: TLS/1.0, HTTP/1.1 > << Connection: Upgrade > << > -- send and complete the TLS handshake > -- server answers the original OPTIONS request > << HTTP/1.1 200 OK > << Date: Sun, 17 Feb 2008 17:23:35 GMT > << Server: Apache > << Content-Length: 0 > << Content-Type: text/plain > << > My reason for developing this protocol socket factory was to support secure > IPP over the standard IPP port. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-763) Behaviour of BasicHttpRequest wrt. path is inconsistent
[
https://issues.apache.org/jira/browse/HTTPCORE-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807126#comment-17807126
]
ASF subversion and git services commented on HTTPCORE-763:
--
Commit 266223192451e5d77a75329f6701701fc66fb709 in httpcomponents-core's branch
refs/heads/5.2.x from Marco Bungart
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=266223192 ]
HTTPCORE-763: remove checks that assert a path does not start with "//"
> Behaviour of BasicHttpRequest wrt. path is inconsistent
> ---
>
> Key: HTTPCORE-763
> URL: https://issues.apache.org/jira/browse/HTTPCORE-763
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
>Affects Versions: 5.1, 5.2, 5.3-alpha1
>Reporter: Marco Bungart
>Priority: Minor
> Fix For: 5.3-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The [Setter for {{path}} in
> {{BasicHttpRequest}}|https://github.com/apache/httpcomponents-core/blob/26b3bc6d6dc56587afdb12d84361009d55a5197f/httpcore5/src/main/java/org/apache/hc/core5/http/message/BasicHttpRequest.java#L210]
> checks whether the parameter {{path}} starts with two slashes and - if so -
> throws an {{IllegalArgumentException}} (through the call to
> [{{Args.check(...)}}|https://github.com/apache/httpcomponents-core/blob/26b3bc6d6dc56587afdb12d84361009d55a5197f/httpcore5/src/main/java/org/apache/hc/core5/util/Args.java#L39].
> Similarly, method
> [{{setUri(...)}}|https://github.com/apache/httpcomponents-core/blob/26b3bc6d6dc56587afdb12d84361009d55a5197f/httpcore5/src/main/java/org/apache/hc/core5/http/message/BasicHttpRequest.java#L264]
> checks the raw path from tur {{URI}}.
> This leads to inconsistent behaviour. A constructor call like:
> {code:java}
> new BasicHttpRequest("GET", "http", URIAuthority.create("google.com"),
> "//search/asdf?q=foobar");
> {code}
> works fine, while a constructor call like:
> {code:java}
> new BasicHttpRequest("GET", "http", URIAuthority.create("google.com"),
> "doesNotMatter")
> .setPath("//search/asdf?q=foobar");
> {code}
> or
> {code:java}
> new BasicHttpRequest("GET",
> URI.create("https://www.google.com//search/asdf?q=foobar;));
> {code}
> throws an {{{}IllegalArgumentException{}}}.
> The Class {{BasicHttpRequest}} was extended in [commit
> {{1614d5d}}|https://github.com/apache/httpcomponents-core/commit/1614d5d5a5de6f4faadff9ecb566982d56b65179]
> and is present since.
> I think what should happen is that the path should only be checked for {{//}}
> if the {{authority}} is not set since [RFC 3986 in section
> 3|https://www.rfc-editor.org/rfc/rfc3986#section-3] specifies:
> {code}
>The scheme and path components are required, though the path may be
>empty (no characters). When authority is present, the path must
>either be empty or begin with a slash ("/") character. When
>authority is not present, the path cannot begin with two slash
>characters ("//").
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-763) Behaviour of BasicHttpRequest wrt. path is inconsistent
[
https://issues.apache.org/jira/browse/HTTPCORE-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806897#comment-17806897
]
ASF subversion and git services commented on HTTPCORE-763:
--
Commit c99f4a81677cd34b17c7e73eef47654acb8713d5 in httpcomponents-core's branch
refs/heads/master from Marco Bungart
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=c99f4a816 ]
HTTPCORE-763: remove checks that assert a path does not start with "//"
> Behaviour of BasicHttpRequest wrt. path is inconsistent
> ---
>
> Key: HTTPCORE-763
> URL: https://issues.apache.org/jira/browse/HTTPCORE-763
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
>Affects Versions: 5.1, 5.2, 5.3-alpha1
>Reporter: Marco Bungart
>Priority: Minor
> Fix For: 5.3-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The [Setter for {{path}} in
> {{BasicHttpRequest}}|https://github.com/apache/httpcomponents-core/blob/26b3bc6d6dc56587afdb12d84361009d55a5197f/httpcore5/src/main/java/org/apache/hc/core5/http/message/BasicHttpRequest.java#L210]
> checks whether the parameter {{path}} starts with two slashes and - if so -
> throws an {{IllegalArgumentException}} (through the call to
> [{{Args.check(...)}}|https://github.com/apache/httpcomponents-core/blob/26b3bc6d6dc56587afdb12d84361009d55a5197f/httpcore5/src/main/java/org/apache/hc/core5/util/Args.java#L39].
> Similarly, method
> [{{setUri(...)}}|https://github.com/apache/httpcomponents-core/blob/26b3bc6d6dc56587afdb12d84361009d55a5197f/httpcore5/src/main/java/org/apache/hc/core5/http/message/BasicHttpRequest.java#L264]
> checks the raw path from tur {{URI}}.
> This leads to inconsistent behaviour. A constructor call like:
> {code:java}
> new BasicHttpRequest("GET", "http", URIAuthority.create("google.com"),
> "//search/asdf?q=foobar");
> {code}
> works fine, while a constructor call like:
> {code:java}
> new BasicHttpRequest("GET", "http", URIAuthority.create("google.com"),
> "doesNotMatter")
> .setPath("//search/asdf?q=foobar");
> {code}
> or
> {code:java}
> new BasicHttpRequest("GET",
> URI.create("https://www.google.com//search/asdf?q=foobar;));
> {code}
> throws an {{{}IllegalArgumentException{}}}.
> The Class {{BasicHttpRequest}} was extended in [commit
> {{1614d5d}}|https://github.com/apache/httpcomponents-core/commit/1614d5d5a5de6f4faadff9ecb566982d56b65179]
> and is present since.
> I think what should happen is that the path should only be checked for {{//}}
> if the {{authority}} is not set since [RFC 3986 in section
> 3|https://www.rfc-editor.org/rfc/rfc3986#section-3] specifies:
> {code}
>The scheme and path components are required, though the path may be
>empty (no characters). When authority is present, the path must
>either be empty or begin with a slash ("/") character. When
>authority is not present, the path cannot begin with two slash
>characters ("//").
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2315) Inconsistent observance of system properties when using HttpClients.createSystem
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804327#comment-17804327 ] ASF subversion and git services commented on HTTPCLIENT-2315: - Commit ef77109f35347fa46f1b0d7a33b945d34fbf43bf in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ef77109f3 ] HTTPCLIENT-2315: client builders fails to apply system properties to the default connection manager > Inconsistent observance of system properties when using > HttpClients.createSystem > > > Key: HTTPCLIENT-2315 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2315 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 5.3 >Reporter: Vitor Dantas >Priority: Minor > Fix For: 5.3.1 > > > During the startup of my application, I configure an SSLContext with > additional certificates and set it as a global default using > SSLContext.setDefault. Subsequently, all requests created without explicit > configuration can successfully connect to servers requiring these > certificates. This setup functions seamlessly with various APIs I currently > utilize: > * java.net.URLConnection (e.g., URLConnection conn = url.openConnection()) > * java.net.http.HttpClient (e.g., HttpClient client = > HttpClient.newHttpClient()) > * org.springframework.ws.client.core.WebServiceTemplate (e.g., > WebServiceTemplate webServiceTemplate = new WebServiceTemplate()) > Previously, this approach worked flawlessly with > org.apache.httpcomponents:httpclient:4.5.14, where clients were created using: > HttpClient httpclient = > org.apache.http.impl.client.HttpClients.createSystem(); > However, issues arise (due to missing certificates) after upgrading to > org.apache.httpcomponents.client5:httpclient5:5.3 and creating clients with: > HttpClient httpclient = > org.apache.hc.client5.http.impl.classic.HttpClients.createSystem(); > When creating a client with > HttpClientBuilder.create().useSystemProperties().build() or more succinctly > with HttpClients.createSystem(), the expectation is that system properties > are observed throughout. > However, upon inspecting the code, it becomes evident that the connection > manager underneath is created using > PoolingHttpClientConnectionManagerBuilder.create().build(), and not > PoolingHttpClientConnectionManagerBuilder.create().useSystemProperties().build() > as one might anticipate. > Consequently, an internal condition registers the HTTPS socketFactory using > SSLConnectionSocketFactory.getSocketFactory() instead of > SSLConnectionSocketFactory.getSystemSocketFactory(). This, in turn, results > in the creation of a new SSLContext.getInstance(SSLContextBuilder.TLS) > instead of leveraging the default one through SSLSocketFactory.getDefault(). > Why is this the case? Is it possible to change this behavior so that the > configuration is simplified when one aims to use the default socket factory? > Specifically, without the need for explicit configuration of the connection > manager in such a common scenario. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2315) Inconsistent observance of system properties when using HttpClients.createSystem
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804320#comment-17804320 ] ASF subversion and git services commented on HTTPCLIENT-2315: - Commit 679991ae33ce8880d7a1739c5a10ab1b2146d31a in httpcomponents-client's branch refs/heads/5.3.x from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=679991ae3 ] HTTPCLIENT-2315: client builders fails to apply system properties to the default connection manager > Inconsistent observance of system properties when using > HttpClients.createSystem > > > Key: HTTPCLIENT-2315 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2315 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 5.3 >Reporter: Vitor Dantas >Priority: Minor > Fix For: 5.3.1 > > > During the startup of my application, I configure an SSLContext with > additional certificates and set it as a global default using > SSLContext.setDefault. Subsequently, all requests created without explicit > configuration can successfully connect to servers requiring these > certificates. This setup functions seamlessly with various APIs I currently > utilize: > * java.net.URLConnection (e.g., URLConnection conn = url.openConnection()) > * java.net.http.HttpClient (e.g., HttpClient client = > HttpClient.newHttpClient()) > * org.springframework.ws.client.core.WebServiceTemplate (e.g., > WebServiceTemplate webServiceTemplate = new WebServiceTemplate()) > Previously, this approach worked flawlessly with > org.apache.httpcomponents:httpclient:4.5.14, where clients were created using: > HttpClient httpclient = > org.apache.http.impl.client.HttpClients.createSystem(); > However, issues arise (due to missing certificates) after upgrading to > org.apache.httpcomponents.client5:httpclient5:5.3 and creating clients with: > HttpClient httpclient = > org.apache.hc.client5.http.impl.classic.HttpClients.createSystem(); > When creating a client with > HttpClientBuilder.create().useSystemProperties().build() or more succinctly > with HttpClients.createSystem(), the expectation is that system properties > are observed throughout. > However, upon inspecting the code, it becomes evident that the connection > manager underneath is created using > PoolingHttpClientConnectionManagerBuilder.create().build(), and not > PoolingHttpClientConnectionManagerBuilder.create().useSystemProperties().build() > as one might anticipate. > Consequently, an internal condition registers the HTTPS socketFactory using > SSLConnectionSocketFactory.getSocketFactory() instead of > SSLConnectionSocketFactory.getSystemSocketFactory(). This, in turn, results > in the creation of a new SSLContext.getInstance(SSLContextBuilder.TLS) > instead of leveraging the default one through SSLSocketFactory.getDefault(). > Why is this the case? Is it possible to change this behavior so that the > configuration is simplified when one aims to use the default socket factory? > Specifically, without the need for explicit configuration of the connection > manager in such a common scenario. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2315) Inconsistent observance of system properties when using HttpClients.createSystem
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804272#comment-17804272 ] ASF subversion and git services commented on HTTPCLIENT-2315: - Commit 7b12669bd6f70d3534179e8f581ceffdbdbe6b1a in httpcomponents-client's branch refs/heads/HTTPCLIENT-2315 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=7b12669bd ] HTTPCLIENT-2315: client builders fails to apply system properties to the default connection manager > Inconsistent observance of system properties when using > HttpClients.createSystem > > > Key: HTTPCLIENT-2315 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2315 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 5.3 >Reporter: Vitor Dantas >Priority: Minor > Fix For: 5.3.1 > > > During the startup of my application, I configure an SSLContext with > additional certificates and set it as a global default using > SSLContext.setDefault. Subsequently, all requests created without explicit > configuration can successfully connect to servers requiring these > certificates. This setup functions seamlessly with various APIs I currently > utilize: > * java.net.URLConnection (e.g., URLConnection conn = url.openConnection()) > * java.net.http.HttpClient (e.g., HttpClient client = > HttpClient.newHttpClient()) > * org.springframework.ws.client.core.WebServiceTemplate (e.g., > WebServiceTemplate webServiceTemplate = new WebServiceTemplate()) > Previously, this approach worked flawlessly with > org.apache.httpcomponents:httpclient:4.5.14, where clients were created using: > HttpClient httpclient = > org.apache.http.impl.client.HttpClients.createSystem(); > However, issues arise (due to missing certificates) after upgrading to > org.apache.httpcomponents.client5:httpclient5:5.3 and creating clients with: > HttpClient httpclient = > org.apache.hc.client5.http.impl.classic.HttpClients.createSystem(); > When creating a client with > HttpClientBuilder.create().useSystemProperties().build() or more succinctly > with HttpClients.createSystem(), the expectation is that system properties > are observed throughout. > However, upon inspecting the code, it becomes evident that the connection > manager underneath is created using > PoolingHttpClientConnectionManagerBuilder.create().build(), and not > PoolingHttpClientConnectionManagerBuilder.create().useSystemProperties().build() > as one might anticipate. > Consequently, an internal condition registers the HTTPS socketFactory using > SSLConnectionSocketFactory.getSocketFactory() instead of > SSLConnectionSocketFactory.getSystemSocketFactory(). This, in turn, results > in the creation of a new SSLContext.getInstance(SSLContextBuilder.TLS) > instead of leveraging the default one through SSLSocketFactory.getDefault(). > Why is this the case? Is it possible to change this behavior so that the > configuration is simplified when one aims to use the default socket factory? > Specifically, without the need for explicit configuration of the connection > manager in such a common scenario. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2314) IllegalStateException: Endpoint is not connected
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803971#comment-17803971
]
ASF subversion and git services commented on HTTPCLIENT-2314:
-
Commit 8228ddf28a58015f842bebd4e2ab6269f92608dc in httpcomponents-client's
branch refs/heads/master from Philip Helger
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=8228ddf28 ]
HTTPCLIENT-2314: Handle gracefully a failure of DnsResolver to return a list of
resolved addresses (#533)
> IllegalStateException: Endpoint is not connected
>
>
> Key: HTTPCLIENT-2314
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2314
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2, 5.3
>Reporter: Philip Helger
>Priority: Minor
> Fix For: 5.3.1
>
> Attachments: debuglog-httpclient-2314.txt, httpclient-2314-1.txt,
> httpclient-2314-2.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Using `PoolingHttpClientConnectionManager`, under high traffic situations it
> occurs consistently that the exception "Endpoint is not connected" is invoked.
>
> The full stacktrace looks like this:
> {{Caused by: java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)
> ~[httpcore5-5.2.4.jar:5.2.4]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:664)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.setSocketTimeout(PoolingHttpClientConnectionManager.java:697)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.execute(InternalExecRuntime.java:211)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
>
> Unfortunately I don't have a standalone example to reproduce it.
> Any suggestions for a workaround
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2314) IllegalStateException: Endpoint is not connected
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803970#comment-17803970
]
ASF subversion and git services commented on HTTPCLIENT-2314:
-
Commit 16508314d1aefc3b1b978125da9855998d6c2921 in httpcomponents-client's
branch refs/heads/5.3.x from Philip Helger
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=16508314d ]
HTTPCLIENT-2314: Handle gracefully a failure of DnsResolver to return a list of
resolved addresses (#533)
> IllegalStateException: Endpoint is not connected
>
>
> Key: HTTPCLIENT-2314
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2314
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2, 5.3
>Reporter: Philip Helger
>Priority: Minor
> Fix For: 5.3.1
>
> Attachments: debuglog-httpclient-2314.txt, httpclient-2314-1.txt,
> httpclient-2314-2.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Using `PoolingHttpClientConnectionManager`, under high traffic situations it
> occurs consistently that the exception "Endpoint is not connected" is invoked.
>
> The full stacktrace looks like this:
> {{Caused by: java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)
> ~[httpcore5-5.2.4.jar:5.2.4]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:664)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.setSocketTimeout(PoolingHttpClientConnectionManager.java:697)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.execute(InternalExecRuntime.java:211)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
>
> Unfortunately I don't have a standalone example to reproduce it.
> Any suggestions for a workaround
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2314) IllegalStateException: Endpoint is not connected
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803822#comment-17803822
]
ASF subversion and git services commented on HTTPCLIENT-2314:
-
Commit 8996465fcacdad2f4a658df43f6f1984f3656109 in httpcomponents-client's
branch refs/heads/HTTPCLIENT-2314 from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=8996465fc ]
HTTPCLIENT-2314: better handling of DNS failure to resolve an address resulting
in an empty result set more
> IllegalStateException: Endpoint is not connected
>
>
> Key: HTTPCLIENT-2314
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2314
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2, 5.3
>Reporter: Philip Helger
>Priority: Minor
> Fix For: 5.3.1
>
> Attachments: debuglog-httpclient-2314.txt, httpclient-2314-1.txt,
> httpclient-2314-2.txt
>
>
> Using `PoolingHttpClientConnectionManager`, under high traffic situations it
> occurs consistently that the exception "Endpoint is not connected" is invoked.
>
> The full stacktrace looks like this:
> {{Caused by: java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)
> ~[httpcore5-5.2.4.jar:5.2.4]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:664)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.setSocketTimeout(PoolingHttpClientConnectionManager.java:697)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.execute(InternalExecRuntime.java:211)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
>
> Unfortunately I don't have a standalone example to reproduce it.
> Any suggestions for a workaround
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2314) IllegalStateException: Endpoint is not connected
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803547#comment-17803547
]
ASF subversion and git services commented on HTTPCLIENT-2314:
-
Commit e2385f7d9a7994b3359b224d5454b18ec2b1fc0a in httpcomponents-client's
branch refs/heads/master from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=e2385f7d9 ]
HTTPCLIENT-2314: Throw ConnectionShutdownException in case of pooled connection
having been closed or discarded instead of plain IllegalStateException
> IllegalStateException: Endpoint is not connected
>
>
> Key: HTTPCLIENT-2314
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2314
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2, 5.3
>Reporter: Philip Helger
>Priority: Major
>
> Using `PoolingHttpClientConnectionManager`, under high traffic situations it
> occurs consistently that the exception "Endpoint is not connected" is invoked.
>
> The full stacktrace looks like this:
> {{Caused by: java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)
> ~[httpcore5-5.2.4.jar:5.2.4]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:664)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.setSocketTimeout(PoolingHttpClientConnectionManager.java:697)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.execute(InternalExecRuntime.java:211)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
>
> Unfortunately I don't have a standalone example to reproduce it.
> Any suggestions for a workaround
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2314) IllegalStateException: Endpoint is not connected
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803545#comment-17803545
]
ASF subversion and git services commented on HTTPCLIENT-2314:
-
Commit 67519a1a89fce9cf0edd870d2344217c811b27f8 in httpcomponents-client's
branch refs/heads/5.3.x from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=67519a1a8 ]
HTTPCLIENT-2314: Throw ConnectionShutdownException in case of pooled connection
having been closed or discarded instead of plain IllegalStateException
> IllegalStateException: Endpoint is not connected
>
>
> Key: HTTPCLIENT-2314
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2314
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2, 5.3
>Reporter: Philip Helger
>Priority: Major
>
> Using `PoolingHttpClientConnectionManager`, under high traffic situations it
> occurs consistently that the exception "Endpoint is not connected" is invoked.
>
> The full stacktrace looks like this:
> {{Caused by: java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)
> ~[httpcore5-5.2.4.jar:5.2.4]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:664)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.setSocketTimeout(PoolingHttpClientConnectionManager.java:697)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.execute(InternalExecRuntime.java:211)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.MainClientExec.execute(MainClientExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:113)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:152)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:116)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
> ~[httpclient5-5.3.jar:5.3]}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
> ~[httpclient5-5.3.jar:5.3]}}
>
> Unfortunately I don't have a standalone example to reproduce it.
> Any suggestions for a workaround
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799109#comment-17799109 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 84461a7dd5d1e3f7ef9c86465801ff98332d093e in httpcomponents-core's branch refs/heads/release-5.3-alpha1 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=84461a7dd ] Revert "HTTPCORE-756 - Deprecate and remove userInfo from URIAuthority and URIBuilder in compliance with RFC 9110. (#418)" This reverts commit f529ead65f0234d2e35d985bef9da8c18c752b2f. > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 8h 40m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799108#comment-17799108 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 84461a7dd5d1e3f7ef9c86465801ff98332d093e in httpcomponents-core's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=84461a7dd ] Revert "HTTPCORE-756 - Deprecate and remove userInfo from URIAuthority and URIBuilder in compliance with RFC 9110. (#418)" This reverts commit f529ead65f0234d2e35d985bef9da8c18c752b2f. > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 8h 40m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796244#comment-17796244 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit a2d88f4280f1d3ee6d51d705187d918d218d56c3 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=a2d88f428 ] HTTPCORE-756: Better name for the standard date pattern > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796245#comment-17796245 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 0ff85f765bf39ad894e090791618995903b82247 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=0ff85f765 ] HTTPCORE-756: client protocol handlers to try to send `Host` as the first header in the request header section per RFC 9110 section 7.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796249#comment-17796249 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 7fea9ef7fa2be53a7631aad9bb484db7347667be in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=7fea9ef7f ] HTTPCORE-756: Improved Transfer-Encoding handling and message frame validity verification per RFC 9112 section 6.1 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796242#comment-17796242 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 181d70834431100c3933611d17a446331de9c98a in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=181d70834 ] HTTPCORE-756: Expect-Continue handshake improvements per RFC 9110 section 10.1.1 * ignore Expect header in requests older than HTTP/1.1 * Servers to respond with 417 in case of unexpected Expect token > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796239#comment-17796239 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit d1f1e33bd65d245741ed79b1314ce623b8ccf5a8 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=d1f1e33bd ] HTTPCORE-756: replace CR, LF, NULL in header values with SP per RFC 9110 section 5.5 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796248#comment-17796248 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 1fef3f9853200bdc682b1250be07787aabfd9001 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=1fef3f985 ] HTTPCORE-756: Stricter parsing of response status code per RFC 9112 section 3.2; less intermediate garbage while parsing response status lines > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796241#comment-17796241 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 584aecdd3701f91815fa0f848da30faea5ee113d in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=584aecdd3 ] HTTPCORE-756: support methods for handling hop-by-hop and connection specific headers (ported from HttpClient cache module) > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796246#comment-17796246 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 64a6ced2f90aa4aab2599f9e4b2b198b1e345caf in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=64a6ced2f ] HTTPCORE-756: Authority from an absolute request URI to take precedence over Host header per RFC 9112 section 3.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-759) Content-Length missing on null entity request content
[ https://issues.apache.org/jira/browse/HTTPCORE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796237#comment-17796237 ] ASF subversion and git services commented on HTTPCORE-759: -- Commit e453a8110ab639d0aa47a57f66023b450d552775 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Billy [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=e453a8110 ] HTTPCORE-759: Add Content-Length to POST, PUT and PATCH with null entity request content (#435) > Content-Length missing on null entity request content > - > > Key: HTTPCORE-759 > URL: https://issues.apache.org/jira/browse/HTTPCORE-759 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore >Affects Versions: 5.2.2 >Reporter: Billy Jaime Beltran >Priority: Minor > Labels: easyfix > Fix For: 5.2.4, 5.3-alpha1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > When making a POST request with an empty body, the following difference in > behaviour was observed. > In HttpComponents 4.4.x, a null body causes a Content-Length zero header to > be added. > In HttpComponents 5.2.x, a null body causes no Content-Length headers being > added. > While upgrading an Apache Camel application, we noticed that this breaks > calls to an upstream IIS server which replies with 411 (Length Required). > That server expects either a Content-Length 0 or a Transfer-Encoding: chunked > header (with a chunk-size of zero) on requests that have a body semantic > (POST, PUT). > As the code currently stands written, if we manually set `Content-Length: 0` > a ProtocolException is thrown > [RequestContent.java:106|https://github.com/apache/httpcomponents-core/blob/e3c770b55602eb9e5a45dfe7c6a07a1adede2c95/httpcore5/src/main/java/org/apache/hc/core5/http/protocol/RequestContent.java#L106] > and if we call the constructor with overwrite, this header is removed anyway > without being replaced. > The previous behaviour (4.x) is documented > [RequestContent.java:102|https://github.com/apache/httpcomponents-core/blob/a5c117028b7c620974304636d52f06f172f1d08b/httpcore/src/main/java/org/apache/http/protocol/RequestContent.java#L102] > > A suggested fix: re-add the null check and set Content-Length to zero. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796243#comment-17796243 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 799d0cdd04dd369ae7995a6275f9d07defa034f6 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=799d0cdd0 ] HTTPCORE-756: Updated response status codes as per RFC 9110 section 18.3 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796238#comment-17796238 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 7e5879db162d0de71362f145a1c48545245ee3e8 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=7e5879db1 ] HTTPCORE-756: server-side request / response protocol conformance checks (#434) > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796240#comment-17796240 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 353b7aaac75266e7ca827aaebb3cf071c74eca0e in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=353b7aaac ] HTTPCORE-756: reject HTTPS requests received over insecure (non-TLS) connection per RFC 9110 section 7.4 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796247#comment-17796247 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 51f3be8b9e203f5b923733d44909fd9b15179a31 in httpcomponents-core's branch refs/heads/dependabot/maven/io.fabric8-docker-maven-plugin-0.43.4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=51f3be8b9 ] HTTPCORE-756: Support for the effective HTTP/1.x protocol level config parameter; HTTP/1.1 endpoints to signal their actual supported protocol level (the minor version in HTTP/1.x) in the message control data as per RFC 9110 section 6.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796233#comment-17796233 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 1fef3f9853200bdc682b1250be07787aabfd9001 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=1fef3f985 ] HTTPCORE-756: Stricter parsing of response status code per RFC 9112 section 3.2; less intermediate garbage while parsing response status lines > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796229#comment-17796229 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit a2d88f4280f1d3ee6d51d705187d918d218d56c3 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=a2d88f428 ] HTTPCORE-756: Better name for the standard date pattern > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796227#comment-17796227 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 181d70834431100c3933611d17a446331de9c98a in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=181d70834 ] HTTPCORE-756: Expect-Continue handshake improvements per RFC 9110 section 10.1.1 * ignore Expect header in requests older than HTTP/1.1 * Servers to respond with 417 in case of unexpected Expect token > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796231#comment-17796231 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 64a6ced2f90aa4aab2599f9e4b2b198b1e345caf in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=64a6ced2f ] HTTPCORE-756: Authority from an absolute request URI to take precedence over Host header per RFC 9112 section 3.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796228#comment-17796228 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 799d0cdd04dd369ae7995a6275f9d07defa034f6 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=799d0cdd0 ] HTTPCORE-756: Updated response status codes as per RFC 9110 section 18.3 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796232#comment-17796232 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 51f3be8b9e203f5b923733d44909fd9b15179a31 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=51f3be8b9 ] HTTPCORE-756: Support for the effective HTTP/1.x protocol level config parameter; HTTP/1.1 endpoints to signal their actual supported protocol level (the minor version in HTTP/1.x) in the message control data as per RFC 9110 section 6.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796226#comment-17796226 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 584aecdd3701f91815fa0f848da30faea5ee113d in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=584aecdd3 ] HTTPCORE-756: support methods for handling hop-by-hop and connection specific headers (ported from HttpClient cache module) > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796225#comment-17796225 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 353b7aaac75266e7ca827aaebb3cf071c74eca0e in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=353b7aaac ] HTTPCORE-756: reject HTTPS requests received over insecure (non-TLS) connection per RFC 9110 section 7.4 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796224#comment-17796224 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit d1f1e33bd65d245741ed79b1314ce623b8ccf5a8 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=d1f1e33bd ] HTTPCORE-756: replace CR, LF, NULL in header values with SP per RFC 9110 section 5.5 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796223#comment-17796223 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 7e5879db162d0de71362f145a1c48545245ee3e8 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=7e5879db1 ] HTTPCORE-756: server-side request / response protocol conformance checks (#434) > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796230#comment-17796230 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 0ff85f765bf39ad894e090791618995903b82247 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=0ff85f765 ] HTTPCORE-756: client protocol handlers to try to send `Host` as the first header in the request header section per RFC 9110 section 7.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-759) Content-Length missing on null entity request content
[ https://issues.apache.org/jira/browse/HTTPCORE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796222#comment-17796222 ] ASF subversion and git services commented on HTTPCORE-759: -- Commit e453a8110ab639d0aa47a57f66023b450d552775 in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Billy [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=e453a8110 ] HTTPCORE-759: Add Content-Length to POST, PUT and PATCH with null entity request content (#435) > Content-Length missing on null entity request content > - > > Key: HTTPCORE-759 > URL: https://issues.apache.org/jira/browse/HTTPCORE-759 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore >Affects Versions: 5.2.2 >Reporter: Billy Jaime Beltran >Priority: Minor > Labels: easyfix > Fix For: 5.2.4, 5.3-alpha1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > When making a POST request with an empty body, the following difference in > behaviour was observed. > In HttpComponents 4.4.x, a null body causes a Content-Length zero header to > be added. > In HttpComponents 5.2.x, a null body causes no Content-Length headers being > added. > While upgrading an Apache Camel application, we noticed that this breaks > calls to an upstream IIS server which replies with 411 (Length Required). > That server expects either a Content-Length 0 or a Transfer-Encoding: chunked > header (with a chunk-size of zero) on requests that have a body semantic > (POST, PUT). > As the code currently stands written, if we manually set `Content-Length: 0` > a ProtocolException is thrown > [RequestContent.java:106|https://github.com/apache/httpcomponents-core/blob/e3c770b55602eb9e5a45dfe7c6a07a1adede2c95/httpcore5/src/main/java/org/apache/hc/core5/http/protocol/RequestContent.java#L106] > and if we call the constructor with overwrite, this header is removed anyway > without being replaced. > The previous behaviour (4.x) is documented > [RequestContent.java:102|https://github.com/apache/httpcomponents-core/blob/a5c117028b7c620974304636d52f06f172f1d08b/httpcore/src/main/java/org/apache/http/protocol/RequestContent.java#L102] > > A suggested fix: re-add the null check and set Content-Length to zero. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796234#comment-17796234 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 7fea9ef7fa2be53a7631aad9bb484db7347667be in httpcomponents-core's branch refs/heads/dependabot/maven/io.reactivex.rxjava3-rxjava-3.1.8 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=7fea9ef7f ] HTTPCORE-756: Improved Transfer-Encoding handling and message frame validity verification per RFC 9112 section 6.1 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796197#comment-17796197 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 1492f57a84fcc36b320e736dadb9cae931ca99e7 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=1492f57a8 ] HTTPCLIENT-2277: Cache update bug fix > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796201#comment-17796201 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit abb958ec27aaea53f608fee0534e9e229ff3f54a in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=abb958ec2 ] HTTPCLIENT-2277: Revised cache validation logic for conformance with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796200#comment-17796200 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit ebae9ef7e3878c55a6b61b54e82bc921bbe38b62 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ebae9ef7e ] HTTPCLIENT-2277: Aligned CachedResponseSuitabilityChecker with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796198#comment-17796198 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit fcb86dae1123c59a4552e2de7332fc33ce068bf6 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=fcb86dae1 ] HTTPCLIENT-2277: Do not store AUTHORIZATION request header in the cache entry per RFC 9111 section 3.5 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796199#comment-17796199 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 99eb13934fc2d7605b11541ce27685bf83bc4411 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=99eb13934 ] HTTPCLIENT-2277: Aligned ResponseCachingPolicy with the specification requirements per RFC 9111 section 3 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796195#comment-17796195 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 915b9b34d78aa68459358687af8a5fb522709a1d in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=915b9b34d ] HTTPCLIENT-2293: Better name for the standard date pattern > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2301) BasicHttpClientConnectionManager returns response of previous requests
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796196#comment-17796196
]
ASF subversion and git services commented on HTTPCLIENT-2301:
-
Commit 7724432894209f95dd70708de478465b9fac5e6f in httpcomponents-client's
branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Arturo
Bernal
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=772443289 ]
HTTPCLIENT-2301. Refactor release method to use local conn variable. This
commit updates the release method to use the local conn variable from
internalEndpoint.detach() for accurate state management and resource cleanup,
addressing the issue HTTPCLIENT-2301. (#502)
> BasicHttpClientConnectionManager returns response of previous requests
> --
>
> Key: HTTPCLIENT-2301
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2301
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2.1, 5.3-alpha1
> Environment: JAVA 18
> kotlin 1.7.22
> Ubuntu 22.04 x64
>Reporter: Pierre N.
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: volunteers-wanted
> Fix For: 5.4-alpha1
>
> Attachments: test.kt
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> BasicHttpClientConnectionManager doesn't handle request timeout correctly and
> return the response of a previous request.
> The unit test below should output:
> {quote}
> http://localhost:41751/1 -> 1
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> {quote}
> But instead it returns:
> {quote}
> http://localhost:33875/1 -> 1
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> 2
> http://localhost:33875/3 -> 3
> {quote}
> As you can see it returns 2 when requesting the uri /3 which returned 3.
> Also it timeout on the first request to /3 while it shouldn't.
> Replace with PoolingHttpClientConnectionManager() and it works as expected.
> Kotlin unit test to reproduce :
> {quote}
> import com.github.tomakehurst.wiremock.client.WireMock.*
> import com.github.tomakehurst.wiremock.junit5.WireMockRuntimeInfo
> import com.github.tomakehurst.wiremock.junit5.WireMockTest
> import org.apache.hc.client5.http.classic.methods.HttpGet
> import org.apache.hc.client5.http.config.RequestConfig
> import org.apache.hc.client5.http.impl.classic.CloseableHttpClient
> import org.apache.hc.client5.http.impl.classic.HttpClients
> import org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager
> import org.apache.hc.core5.http.io.entity.EntityUtils
> import org.apache.hc.core5.util.Timeout
> import org.junit.jupiter.api.Test
> @WireMockTest
> internal class HttpClientRaceConditionDebug {
> @Test
> fun `debugging z`(wm: WireMockRuntimeInfo) {
> stubFor(get(urlEqualTo("/1")).willReturn(aResponse().withBody("1")))
>
> stubFor(get(urlEqualTo("/2")).willReturn(aResponse().withFixedDelay(2000).withBody("2")))
> stubFor(get(urlEqualTo("/3")).willReturn(aResponse().withBody("3")))
> val client = HttpClients.custom()
> .setConnectionManager(BasicHttpClientConnectionManager())
> //.setConnectionManager(PoolingHttpClientConnectionManager())
> .setDefaultRequestConfig(
> RequestConfig.custom()
> .setResponseTimeout(Timeout.ofSeconds(1))
> .build()
> )
> .build()
> client.executeAndLog("${wm.httpBaseUrl}/1")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> }
> private fun CloseableHttpClient.executeAndLog(uri: String) {
> try {
> execute(HttpGet(uri)) { println("$uri ->
> ${EntityUtils.toString(it.entity)}") }
> } catch (ex: Exception) {
> println("$uri -> $ex")
> }
> }
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796194#comment-17796194 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 4b7986370f7d9085942ba998fac5bc18387a86c0 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/setup-java-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=4b7986370 ] HTTPCLIENT-2293: client protocol handlers to try to send `Host` as the first header in the request header section per RFC 9110 section 7.2 > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796191#comment-17796191 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 7fea9ef7fa2be53a7631aad9bb484db7347667be in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=7fea9ef7f ] HTTPCORE-756: Improved Transfer-Encoding handling and message frame validity verification per RFC 9112 section 6.1 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796183#comment-17796183 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 584aecdd3701f91815fa0f848da30faea5ee113d in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=584aecdd3 ] HTTPCORE-756: support methods for handling hop-by-hop and connection specific headers (ported from HttpClient cache module) > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796187#comment-17796187 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 0ff85f765bf39ad894e090791618995903b82247 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=0ff85f765 ] HTTPCORE-756: client protocol handlers to try to send `Host` as the first header in the request header section per RFC 9110 section 7.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796178#comment-17796178 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 286442bf7f3fb02e10ab4d974b6ea26069d6eaa5 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=286442bf7 ] HTTPCORE-756 - Implement RFC9110 Content-Type validation for OPTIONS requests. Enforce the presence of a valid Content-Type header for OPTIONS requests containing content, as per RFC9110. (#424) > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796189#comment-17796189 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 51f3be8b9e203f5b923733d44909fd9b15179a31 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=51f3be8b9 ] HTTPCORE-756: Support for the effective HTTP/1.x protocol level config parameter; HTTP/1.1 endpoints to signal their actual supported protocol level (the minor version in HTTP/1.x) in the message control data as per RFC 9110 section 6.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796181#comment-17796181 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit d1f1e33bd65d245741ed79b1314ce623b8ccf5a8 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=d1f1e33bd ] HTTPCORE-756: replace CR, LF, NULL in header values with SP per RFC 9110 section 5.5 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796177#comment-17796177 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit f8721abbc8cf6bb3681ee77dc0e2439568d25393 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=f8721abbc ] HTTPCORE-756 - Enforced non-empty host identifier for http/https URIs. (#423) - Modified URIBuilder's build() method to throw an exception for http and https URIs with an empty host identifier, aligning with RFC 9110, Sections 4.2.2 and 4.2.1 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796182#comment-17796182 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 353b7aaac75266e7ca827aaebb3cf071c74eca0e in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=353b7aaac ] HTTPCORE-756: reject HTTPS requests received over insecure (non-TLS) connection per RFC 9110 section 7.4 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796190#comment-17796190 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 1fef3f9853200bdc682b1250be07787aabfd9001 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=1fef3f985 ] HTTPCORE-756: Stricter parsing of response status code per RFC 9112 section 3.2; less intermediate garbage while parsing response status lines > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796188#comment-17796188 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 64a6ced2f90aa4aab2599f9e4b2b198b1e345caf in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=64a6ced2f ] HTTPCORE-756: Authority from an absolute request URI to take precedence over Host header per RFC 9112 section 3.2 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796184#comment-17796184 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 181d70834431100c3933611d17a446331de9c98a in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=181d70834 ] HTTPCORE-756: Expect-Continue handshake improvements per RFC 9110 section 10.1.1 * ignore Expect header in requests older than HTTP/1.1 * Servers to respond with 417 in case of unexpected Expect token > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796180#comment-17796180 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 7e5879db162d0de71362f145a1c48545245ee3e8 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=7e5879db1 ] HTTPCORE-756: server-side request / response protocol conformance checks (#434) > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796186#comment-17796186 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit a2d88f4280f1d3ee6d51d705187d918d218d56c3 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=a2d88f428 ] HTTPCORE-756: Better name for the standard date pattern > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-759) Content-Length missing on null entity request content
[ https://issues.apache.org/jira/browse/HTTPCORE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796179#comment-17796179 ] ASF subversion and git services commented on HTTPCORE-759: -- Commit e453a8110ab639d0aa47a57f66023b450d552775 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Billy [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=e453a8110 ] HTTPCORE-759: Add Content-Length to POST, PUT and PATCH with null entity request content (#435) > Content-Length missing on null entity request content > - > > Key: HTTPCORE-759 > URL: https://issues.apache.org/jira/browse/HTTPCORE-759 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore >Affects Versions: 5.2.2 >Reporter: Billy Jaime Beltran >Priority: Minor > Labels: easyfix > Fix For: 5.2.4, 5.3-alpha1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > When making a POST request with an empty body, the following difference in > behaviour was observed. > In HttpComponents 4.4.x, a null body causes a Content-Length zero header to > be added. > In HttpComponents 5.2.x, a null body causes no Content-Length headers being > added. > While upgrading an Apache Camel application, we noticed that this breaks > calls to an upstream IIS server which replies with 411 (Length Required). > That server expects either a Content-Length 0 or a Transfer-Encoding: chunked > header (with a chunk-size of zero) on requests that have a body semantic > (POST, PUT). > As the code currently stands written, if we manually set `Content-Length: 0` > a ProtocolException is thrown > [RequestContent.java:106|https://github.com/apache/httpcomponents-core/blob/e3c770b55602eb9e5a45dfe7c6a07a1adede2c95/httpcore5/src/main/java/org/apache/hc/core5/http/protocol/RequestContent.java#L106] > and if we call the constructor with overwrite, this header is removed anyway > without being replaced. > The previous behaviour (4.x) is documented > [RequestContent.java:102|https://github.com/apache/httpcomponents-core/blob/a5c117028b7c620974304636d52f06f172f1d08b/httpcore/src/main/java/org/apache/http/protocol/RequestContent.java#L102] > > A suggested fix: re-add the null check and set Content-Length to zero. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796185#comment-17796185 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit 799d0cdd04dd369ae7995a6275f9d07defa034f6 in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=799d0cdd0 ] HTTPCORE-756: Updated response status codes as per RFC 9110 section 18.3 > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796172#comment-17796172 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit fcb86dae1123c59a4552e2de7332fc33ce068bf6 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=fcb86dae1 ] HTTPCLIENT-2277: Do not store AUTHORIZATION request header in the cache entry per RFC 9111 section 3.5 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCORE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796176#comment-17796176 ] ASF subversion and git services commented on HTTPCORE-756: -- Commit f529ead65f0234d2e35d985bef9da8c18c752b2f in httpcomponents-core's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=f529ead65 ] HTTPCORE-756 - Deprecate and remove userInfo from URIAuthority and URIBuilder in compliance with RFC 9110. (#418) Removed all references to `userInfo` in the `URIAuthority` class and deprecated methods that utilize `userInfo` in both `URIAuthority` and `URIBuilder`. This change aligns with the RFC's recommendation against using the `userinfo` subcomponent in "http" or "https" URIs. > HttpCore HTTP Semantics conformance to RFC 9110 > --- > > Key: HTTPCORE-756 > URL: https://issues.apache.org/jira/browse/HTTPCORE-756 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.3-alpha1 > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Ensure HttpCore conforms to RFC 9110. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796174#comment-17796174 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit ebae9ef7e3878c55a6b61b54e82bc921bbe38b62 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ebae9ef7e ] HTTPCLIENT-2277: Aligned CachedResponseSuitabilityChecker with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796171#comment-17796171 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 1492f57a84fcc36b320e736dadb9cae931ca99e7 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=1492f57a8 ] HTTPCLIENT-2277: Cache update bug fix > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796173#comment-17796173 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 99eb13934fc2d7605b11541ce27685bf83bc4411 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=99eb13934 ] HTTPCLIENT-2277: Aligned ResponseCachingPolicy with the specification requirements per RFC 9111 section 3 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2301) BasicHttpClientConnectionManager returns response of previous requests
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796170#comment-17796170
]
ASF subversion and git services commented on HTTPCLIENT-2301:
-
Commit 7724432894209f95dd70708de478465b9fac5e6f in httpcomponents-client's
branch refs/heads/dependabot/github_actions/actions/checkout-4 from Arturo
Bernal
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=772443289 ]
HTTPCLIENT-2301. Refactor release method to use local conn variable. This
commit updates the release method to use the local conn variable from
internalEndpoint.detach() for accurate state management and resource cleanup,
addressing the issue HTTPCLIENT-2301. (#502)
> BasicHttpClientConnectionManager returns response of previous requests
> --
>
> Key: HTTPCLIENT-2301
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2301
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2.1, 5.3-alpha1
> Environment: JAVA 18
> kotlin 1.7.22
> Ubuntu 22.04 x64
>Reporter: Pierre N.
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: volunteers-wanted
> Fix For: 5.4-alpha1
>
> Attachments: test.kt
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> BasicHttpClientConnectionManager doesn't handle request timeout correctly and
> return the response of a previous request.
> The unit test below should output:
> {quote}
> http://localhost:41751/1 -> 1
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> {quote}
> But instead it returns:
> {quote}
> http://localhost:33875/1 -> 1
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> 2
> http://localhost:33875/3 -> 3
> {quote}
> As you can see it returns 2 when requesting the uri /3 which returned 3.
> Also it timeout on the first request to /3 while it shouldn't.
> Replace with PoolingHttpClientConnectionManager() and it works as expected.
> Kotlin unit test to reproduce :
> {quote}
> import com.github.tomakehurst.wiremock.client.WireMock.*
> import com.github.tomakehurst.wiremock.junit5.WireMockRuntimeInfo
> import com.github.tomakehurst.wiremock.junit5.WireMockTest
> import org.apache.hc.client5.http.classic.methods.HttpGet
> import org.apache.hc.client5.http.config.RequestConfig
> import org.apache.hc.client5.http.impl.classic.CloseableHttpClient
> import org.apache.hc.client5.http.impl.classic.HttpClients
> import org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager
> import org.apache.hc.core5.http.io.entity.EntityUtils
> import org.apache.hc.core5.util.Timeout
> import org.junit.jupiter.api.Test
> @WireMockTest
> internal class HttpClientRaceConditionDebug {
> @Test
> fun `debugging z`(wm: WireMockRuntimeInfo) {
> stubFor(get(urlEqualTo("/1")).willReturn(aResponse().withBody("1")))
>
> stubFor(get(urlEqualTo("/2")).willReturn(aResponse().withFixedDelay(2000).withBody("2")))
> stubFor(get(urlEqualTo("/3")).willReturn(aResponse().withBody("3")))
> val client = HttpClients.custom()
> .setConnectionManager(BasicHttpClientConnectionManager())
> //.setConnectionManager(PoolingHttpClientConnectionManager())
> .setDefaultRequestConfig(
> RequestConfig.custom()
> .setResponseTimeout(Timeout.ofSeconds(1))
> .build()
> )
> .build()
> client.executeAndLog("${wm.httpBaseUrl}/1")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> }
> private fun CloseableHttpClient.executeAndLog(uri: String) {
> try {
> execute(HttpGet(uri)) { println("$uri ->
> ${EntityUtils.toString(it.entity)}") }
> } catch (ex: Exception) {
> println("$uri -> $ex")
> }
> }
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796169#comment-17796169 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 915b9b34d78aa68459358687af8a5fb522709a1d in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=915b9b34d ] HTTPCLIENT-2293: Better name for the standard date pattern > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796175#comment-17796175 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit abb958ec27aaea53f608fee0534e9e229ff3f54a in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=abb958ec2 ] HTTPCLIENT-2277: Revised cache validation logic for conformance with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796168#comment-17796168 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 4b7986370f7d9085942ba998fac5bc18387a86c0 in httpcomponents-client's branch refs/heads/dependabot/github_actions/actions/checkout-4 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=4b7986370 ] HTTPCLIENT-2293: client protocol handlers to try to send `Host` as the first header in the request header section per RFC 9110 section 7.2 > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796148#comment-17796148 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 4b7986370f7d9085942ba998fac5bc18387a86c0 in httpcomponents-client's branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=4b7986370 ] HTTPCLIENT-2293: client protocol handlers to try to send `Host` as the first header in the request header section per RFC 9110 section 7.2 > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796145#comment-17796145 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit ebae9ef7e3878c55a6b61b54e82bc921bbe38b62 in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ebae9ef7e ] HTTPCLIENT-2277: Aligned CachedResponseSuitabilityChecker with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796153#comment-17796153 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 99eb13934fc2d7605b11541ce27685bf83bc4411 in httpcomponents-client's branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=99eb13934 ] HTTPCLIENT-2277: Aligned ResponseCachingPolicy with the specification requirements per RFC 9111 section 3 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796152#comment-17796152 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit fcb86dae1123c59a4552e2de7332fc33ce068bf6 in httpcomponents-client's branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=fcb86dae1 ] HTTPCLIENT-2277: Do not store AUTHORIZATION request header in the cache entry per RFC 9111 section 3.5 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796140#comment-17796140 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 915b9b34d78aa68459358687af8a5fb522709a1d in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=915b9b34d ] HTTPCLIENT-2293: Better name for the standard date pattern > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2301) BasicHttpClientConnectionManager returns response of previous requests
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796150#comment-17796150
]
ASF subversion and git services commented on HTTPCLIENT-2301:
-
Commit 7724432894209f95dd70708de478465b9fac5e6f in httpcomponents-client's
branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=772443289 ]
HTTPCLIENT-2301. Refactor release method to use local conn variable. This
commit updates the release method to use the local conn variable from
internalEndpoint.detach() for accurate state management and resource cleanup,
addressing the issue HTTPCLIENT-2301. (#502)
> BasicHttpClientConnectionManager returns response of previous requests
> --
>
> Key: HTTPCLIENT-2301
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2301
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2.1, 5.3-alpha1
> Environment: JAVA 18
> kotlin 1.7.22
> Ubuntu 22.04 x64
>Reporter: Pierre N.
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: volunteers-wanted
> Fix For: 5.4-alpha1
>
> Attachments: test.kt
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> BasicHttpClientConnectionManager doesn't handle request timeout correctly and
> return the response of a previous request.
> The unit test below should output:
> {quote}
> http://localhost:41751/1 -> 1
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> {quote}
> But instead it returns:
> {quote}
> http://localhost:33875/1 -> 1
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> 2
> http://localhost:33875/3 -> 3
> {quote}
> As you can see it returns 2 when requesting the uri /3 which returned 3.
> Also it timeout on the first request to /3 while it shouldn't.
> Replace with PoolingHttpClientConnectionManager() and it works as expected.
> Kotlin unit test to reproduce :
> {quote}
> import com.github.tomakehurst.wiremock.client.WireMock.*
> import com.github.tomakehurst.wiremock.junit5.WireMockRuntimeInfo
> import com.github.tomakehurst.wiremock.junit5.WireMockTest
> import org.apache.hc.client5.http.classic.methods.HttpGet
> import org.apache.hc.client5.http.config.RequestConfig
> import org.apache.hc.client5.http.impl.classic.CloseableHttpClient
> import org.apache.hc.client5.http.impl.classic.HttpClients
> import org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager
> import org.apache.hc.core5.http.io.entity.EntityUtils
> import org.apache.hc.core5.util.Timeout
> import org.junit.jupiter.api.Test
> @WireMockTest
> internal class HttpClientRaceConditionDebug {
> @Test
> fun `debugging z`(wm: WireMockRuntimeInfo) {
> stubFor(get(urlEqualTo("/1")).willReturn(aResponse().withBody("1")))
>
> stubFor(get(urlEqualTo("/2")).willReturn(aResponse().withFixedDelay(2000).withBody("2")))
> stubFor(get(urlEqualTo("/3")).willReturn(aResponse().withBody("3")))
> val client = HttpClients.custom()
> .setConnectionManager(BasicHttpClientConnectionManager())
> //.setConnectionManager(PoolingHttpClientConnectionManager())
> .setDefaultRequestConfig(
> RequestConfig.custom()
> .setResponseTimeout(Timeout.ofSeconds(1))
> .build()
> )
> .build()
> client.executeAndLog("${wm.httpBaseUrl}/1")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> }
> private fun CloseableHttpClient.executeAndLog(uri: String) {
> try {
> execute(HttpGet(uri)) { println("$uri ->
> ${EntityUtils.toString(it.entity)}") }
> } catch (ex: Exception) {
> println("$uri -> $ex")
> }
> }
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796143#comment-17796143 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit fcb86dae1123c59a4552e2de7332fc33ce068bf6 in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=fcb86dae1 ] HTTPCLIENT-2277: Do not store AUTHORIZATION request header in the cache entry per RFC 9111 section 3.5 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796144#comment-17796144 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 99eb13934fc2d7605b11541ce27685bf83bc4411 in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=99eb13934 ] HTTPCLIENT-2277: Aligned ResponseCachingPolicy with the specification requirements per RFC 9111 section 3 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796155#comment-17796155 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit abb958ec27aaea53f608fee0534e9e229ff3f54a in httpcomponents-client's branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=abb958ec2 ] HTTPCLIENT-2277: Revised cache validation logic for conformance with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796146#comment-17796146 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit abb958ec27aaea53f608fee0534e9e229ff3f54a in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=abb958ec2 ] HTTPCLIENT-2277: Revised cache validation logic for conformance with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796151#comment-17796151 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 1492f57a84fcc36b320e736dadb9cae931ca99e7 in httpcomponents-client's branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=1492f57a8 ] HTTPCLIENT-2277: Cache update bug fix > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796147#comment-17796147 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 77fdc11818f2bd5b21c4b2e1db676c7263296b01 in httpcomponents-client's branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=77fdc1181 ] HTTPCLIENT-2293: Via header improvements * optimized parting of Via response header values in order to generate less intermediate garbage * optimized Via message header generation * moved Via request header generation to a cache request interceptor * moved Via response header generation to a cache response interceptor > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796142#comment-17796142 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit 1492f57a84fcc36b320e736dadb9cae931ca99e7 in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=1492f57a8 ] HTTPCLIENT-2277: Cache update bug fix > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2277) HttpClient Cache conformance to RFC 9111
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796154#comment-17796154 ] ASF subversion and git services commented on HTTPCLIENT-2277: - Commit ebae9ef7e3878c55a6b61b54e82bc921bbe38b62 in httpcomponents-client's branch refs/heads/dependabot/maven/log4j.version-2.22.0 from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ebae9ef7e ] HTTPCLIENT-2277: Aligned CachedResponseSuitabilityChecker with the specification requirements per RFC 9111 section 4 > HttpClient Cache conformance to RFC 9111 > > > Key: HTTPCLIENT-2277 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2277 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpCache >Reporter: Oleg Kalnichevski >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 15h 40m > Remaining Estimate: 0h > > Ensure HttpClient Cache conforms to RFC 9111. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2301) BasicHttpClientConnectionManager returns response of previous requests
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796141#comment-17796141
]
ASF subversion and git services commented on HTTPCLIENT-2301:
-
Commit 7724432894209f95dd70708de478465b9fac5e6f in httpcomponents-client's
branch refs/heads/master from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=772443289 ]
HTTPCLIENT-2301. Refactor release method to use local conn variable. This
commit updates the release method to use the local conn variable from
internalEndpoint.detach() for accurate state management and resource cleanup,
addressing the issue HTTPCLIENT-2301. (#502)
> BasicHttpClientConnectionManager returns response of previous requests
> --
>
> Key: HTTPCLIENT-2301
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2301
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.2.1, 5.3-alpha1
> Environment: JAVA 18
> kotlin 1.7.22
> Ubuntu 22.04 x64
>Reporter: Pierre N.
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: volunteers-wanted
> Fix For: 5.4-alpha1
>
> Attachments: test.kt
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> BasicHttpClientConnectionManager doesn't handle request timeout correctly and
> return the response of a previous request.
> The unit test below should output:
> {quote}
> http://localhost:41751/1 -> 1
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> http://localhost:41751/3 -> 3
> {quote}
> But instead it returns:
> {quote}
> http://localhost:33875/1 -> 1
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/2 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> java.net.SocketTimeoutException: Read timed out
> http://localhost:33875/3 -> 2
> http://localhost:33875/3 -> 3
> {quote}
> As you can see it returns 2 when requesting the uri /3 which returned 3.
> Also it timeout on the first request to /3 while it shouldn't.
> Replace with PoolingHttpClientConnectionManager() and it works as expected.
> Kotlin unit test to reproduce :
> {quote}
> import com.github.tomakehurst.wiremock.client.WireMock.*
> import com.github.tomakehurst.wiremock.junit5.WireMockRuntimeInfo
> import com.github.tomakehurst.wiremock.junit5.WireMockTest
> import org.apache.hc.client5.http.classic.methods.HttpGet
> import org.apache.hc.client5.http.config.RequestConfig
> import org.apache.hc.client5.http.impl.classic.CloseableHttpClient
> import org.apache.hc.client5.http.impl.classic.HttpClients
> import org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager
> import org.apache.hc.core5.http.io.entity.EntityUtils
> import org.apache.hc.core5.util.Timeout
> import org.junit.jupiter.api.Test
> @WireMockTest
> internal class HttpClientRaceConditionDebug {
> @Test
> fun `debugging z`(wm: WireMockRuntimeInfo) {
> stubFor(get(urlEqualTo("/1")).willReturn(aResponse().withBody("1")))
>
> stubFor(get(urlEqualTo("/2")).willReturn(aResponse().withFixedDelay(2000).withBody("2")))
> stubFor(get(urlEqualTo("/3")).willReturn(aResponse().withBody("3")))
> val client = HttpClients.custom()
> .setConnectionManager(BasicHttpClientConnectionManager())
> //.setConnectionManager(PoolingHttpClientConnectionManager())
> .setDefaultRequestConfig(
> RequestConfig.custom()
> .setResponseTimeout(Timeout.ofSeconds(1))
> .build()
> )
> .build()
> client.executeAndLog("${wm.httpBaseUrl}/1")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/2")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> client.executeAndLog("${wm.httpBaseUrl}/3")
> }
> private fun CloseableHttpClient.executeAndLog(uri: String) {
> try {
> execute(HttpGet(uri)) { println("$uri ->
> ${EntityUtils.toString(it.entity)}") }
> } catch (ex: Exception) {
> println("$uri -> $ex")
> }
> }
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796139#comment-17796139 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 4b7986370f7d9085942ba998fac5bc18387a86c0 in httpcomponents-client's branch refs/heads/master from Oleg Kalnichevski [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=4b7986370 ] HTTPCLIENT-2293: client protocol handlers to try to send `Host` as the first header in the request header section per RFC 9110 section 7.2 > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2293) HttpClient HTTP Semantics conformance to RFC 9110
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796137#comment-17796137 ] ASF subversion and git services commented on HTTPCLIENT-2293: - Commit 83e0339d27d9b60c797af53cc1bf7c03c954e16d in httpcomponents-client's branch refs/heads/master from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=83e0339d2 ] HTTPCLIENT-2293 - Implement RFC-compliant TRACE request interceptor (#486) - Add RequestTraceInterceptor class to handle HTTP TRACE requests in compliance with RFC 7231, Section 4.3.8. - Throw ProtocolException for sensitive headers like 'Authorization' and 'Cookie' in TRACE requests. - Throw ProtocolException if TRACE request contains a body. > HttpClient HTTP Semantics conformance to RFC 9110 > - > > Key: HTTPCLIENT-2293 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293 > Project: HttpComponents HttpClient > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Major > Fix For: 5.4-alpha1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
