This commit introduces the DistributedProxySelector class, which enables efficient and thread-safe proxy selection among multiple ProxySelector instances. The new class ensures proper distribution of proxy selector usage with the help of AtomicInteger and maintains thread safety using ThreadLocal.
Key features and improvements:
Distributes proxy selection among multiple ProxySelector instances
Ensures thread safety by using ThreadLocal<ProxySelector>
Properly handles exceptions and connection failures
Comprehensive JavaDoc documentation for class, methods, and variables
Includes unit tests for various scenarios and edge cases
This new functionality provides a robust and efficient solution for distributing proxy selection in multi-threaded environments, improving the overall performance and reliability of the system.
Previously, multipart entities did not support adding a preamble or epilogue to the message. This commit adds support for these features by modifying the AbstractMultipartFormat class to accept preamble and epilogue strings in its constructor. The HttpRFC6532Multipart, HttpRFC7578Multipart, and HttpStrictMultipart classes are updated to pass these parameters to the parent constructor when creating instances of multipart entities.
This change allows users to include custom content at the beginning and end of their multipart messages, which can be useful in certain scenarios such as adding metadata or information about the message contents.
This commit enhances the `ContentResponseHandler` class to be more fault-tolerant by handling responses with null or empty bodies without throwing exceptions. If the response was successful (a 2xx status code), the `Content` object is returned. If no response body exists, `Content.NO_CONTENT` is returned.
The implementation extends `ContentResponseHandler` and overrides its methods to handle the response entity and transform it into the actual response object. This is designed to be efficient and use minimal memory.
For digest authentication, in RFC 7616 section "3.4 The Authorization
Header Field":
The values of the opaque and algorithm fields must be those supplied
in the WWW-Authenticate response header field for the entity being
requested.
This commit honors that rule, and removes the previous behavior that
augmented the request header with "algorithm=MD5" when none was provided
in the server's response.
Aside from the specification, it also stands to reason that if the
server failed to provide "algorithm=..." in its "WWW-Authenticate"
header, the server should be fine with the client failing to provide
"algorithm=..." in the "Authorization" header.
The motivation for this change is that including "algorithm=MD5" in the
"Authorization" header causes http requests to fail when made to an
embedded system, which I suspect to be a an Espressif ESP32 web server.
- Super interface already implements FutureCallback
- No need to override methods to only call super
- Add missing Javadoc tag
- Access static field directly
Previously writeTo would conditionally delegate to the wrapped
entity if the provided outputstream was non-null, however in the
null case the entity would not be drained and the connection would
be released potentially with bytes remaining. If this occurs in
practice, it may result in timeouts as the server expects to write
data to the response while the client is attempting to send a
request.
Previously, a partially consumed response body closed via
CloseableHttpResponse.close or HttpEntity.close would fully consume
remaining bytes (via close), however it would not release the
connection for reuse.
If CloseableHttpResponse.close was called, it would follow the close
with a discard/disconnect, however if only the entity was closed,
the connection would remain in a checked-out (leaked) state.
Now, we take advantage of the fact that closing a response stream
on any reusable connection is required to drain bytes on closure.
Failures are detected by writeTo and the stream returned by
getContent, so we can be confident that we will not return a
broken connection to the pool.