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.
* 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
- 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.
* HTTPCLIENT-2277: Deprecated 303 response caching switch as no longer required by RFC 9111
* Javadoc improvements (no functional changes)
* HTTPCLIENT-2277: Revision of HTTP cache protocol requirement and recommendation test cases:
* Removed links to RFC 2616
* Removed verbatim quotes from RFC 2616
* Removed obsolete test cases and test cases without result verification / assertions
* Removed test cases unrelated to HTTP caching
* Removed test cases without test result assertions
- 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`.
* request URI stored in cache is now normalized and is presently expected to be the same as the root key
* removed references to variant cache keys from the cache entry
* Variants in root entries are now represented as a set, not as a map
This commit adds the functionality to handle the 'immutable' directive in the Cache-Control header as per the RFC8246 specifications.
Key changes include:
- The 'immutable' directive is checked in the Cache-Control of an HTTP response, indicating that the origin server will not update the resource representation during the response's freshness lifetime.
- If the 'immutable' directive is present and the response is still fresh, the response is considered cacheable without further validation.
- Ignoring any arguments with the 'immutable' directive, as per RFC stipulations.
- Treating multiple instances of the 'immutable' directive as equivalent to one.
Oleg Kalnichevski
dependabot[bot]
Arturo Bernal