Introduces validation and decoding logic for the 'username*' field in the DigestScheme class. The changes ensure compliance with RFC 7616 and RFC 5987 by handling cases where the 'username' contains characters not allowed in an ABNF quoted-string.
This commit introduces support for the userhash parameter in Digest Authentication, conforming to the specifications outlined in RFC 7616. The userhash parameter enhances security by allowing the client to hash the username before transmission, thereby protecting the username during transport. This implementation ensures that when the server indicates support for username hashing (userhash=true), the client correctly calculates and includes the hashed username in the Authorization header field, adhering to the protocol defined in RFC 7616 for enhanced security in HTTP Digest Access Authentication.
This commit enforces the use of the 'UTF-8' encoding scheme as the sole allowed value for character encoding in Digest Authentication, in alignment with the guidelines specified in RFC 7616.
- Deprecated the constructor in BasicSchemeFactory that allows setting a custom Charset.
- Updated the default constructor to use StandardCharsets.UTF_8, aligning with RFC 7617 which mandates UTF-8 encoding for Basic Authentication.
Introduced a new method, `validatePassword`, in the `BasicScheme` class to enforce password validation in line with RFC 7617 standards. This method includes control character validation for passwords, ensuring they adhere to RFC 7617 by not containing any control characters.
* Updates the RequestIfRange class to utilize DateUtils for parsing standard HTTP dates.
* Optimize time difference check in RequestIfRange with Instant API.
- 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.
- Ensure the presence of 'Range' header when 'If-Range' is specified.
- Enforce strong validator requirements when 'If-Range' is paired with a Date.
- Exit processing early if 'Last-Modified' header is missing, ensuring strong validation adherence.
- This adheres to RFC 9110, which states: "There is no default port; a client MUST send the port number even if the CONNECT request is based on a URI reference that contains an authority component with an elided port.
- Replaced `synchronized` blocks with `ReentrantLock` in `LeaseRequest` to better support virtual threads introduced in JDK 21.
- Ensured each `LeaseRequest` instance has its own unique lock for maintaining original synchronization semantics.
- Addressed potential performance and deadlock issues with virtual threads by using explicit lock primitives from `java.util.concurrent.locks`.
This commit enhances the ExponentialBackoffManager and TestLinearBackoffManager unit tests by replacing the use of Thread.sleep() with direct manipulation of internal state to simulate the cooldown period. This change improves test reliability and ensures consistent behavior in resource-constrained environments.
This commit improves the reliability of BackoffManager unit tests by replacing the use of Thread.sleep() with a more robust approach that manipulates lastRouteProbes to simulate the cooldown period. This enhancement ensures that the tests run successfully even in resource-constrained environments, making them more resilient and reliable.
Enhanced test robustness for AIMDBackoffManager by introducing buffers to sleep durations in cooldown-related tests and adjusting the concurrency test. Due to persistent instability, removed the time-dependent `probeDoesNotAdjustDuringCooldownPeriod` test.
- Create AbstractBackoff class as a base for different backoff strategies
- Add LinearBackoffManager class for implementing linear backoff algorithm in networking and communication systems. This class provides a thread-safe and configurable implementation of linear backoff, allowing for gradual adjustment of maximum connection pool sizes for a given route based on traffic and other factors. The class supports customizable cool-down periods and increment values for each route, and uses a ConcurrentHashMap to ensure thread safety and accurate tracking of backoff and probe attempts
- Implement ExponentialBackoffManager for connection pool control.
This commit introduces the ExponentialBackoffManager class, which manages the connection pool control for HTTP routes based on the Exponential Backoff algorithm. This implementation helps improve connection handling and stability in case of connection failures or network issues.
In this commit, we have made several improvements to the AIMDBackoffManager class:
* Replaced volatile variables with AtomicReference and AtomicInteger to ensure better thread-safety and atomic operations.
* Updated the @Contract annotation to reflect the new thread-safe behavior of the class.
* Added parameter validation checks to public methods for better error handling and prevention of incorrect usage.
* Improved the code readability and organization by separating sections of the class with blank lines and consistent indentation.
* These enhancements make the AIMDBackoffManager class more robust, reliable, and easier to maintain.
This change modifies the NTCredentials class to determine the local workstation name at runtime or request time, in line with the underlying NTLM implementation. The deprecated constructor with the workstation parameter is replaced with a new constructor that does not require the workstation parameter. Instead, it automatically retrieves the workstation name using the getWorkstationName() method.
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.
Updated AbstractClientTlsStrategy to pass only the HttpVersionPolicy set by TlsConfig instead of the entire TlsConfig to H2TlsSupport.selectApplicationProtocols() method.
This fixes an issue in which connections were not returned to the
pool when requests contained non-repeatable bodies AND responses
were streamed. When both of these criteria were met, responses
were returned without ResponseEntityProxy enhancements so that
closing the response entity or stream no longer completed the
exchange, thus leaking the connection which forever lived in the
`leased` state in the connection pool.