* Complies with rfc7231 about statuses 307 and 308
Author: Vladimir Kravets <vova.kravets@gmail.com>
* Add revert test
* Remove @NotNull annotations; we don’t use ’em.
Co-authored-by: Vladimir Kravets <vova.kravets@gmail.com>
Co-authored-by: Jesse Wilson <jesse@swank.ca>
Still to do:
- API to get the boundary parameter from a MediaType
- API to create a MultipartReader from a ResponseBody
- Update to support RFC 2387 features?
As originally designed DiskLruCache assumes an inode-like
file system, where it's fine to delete files that are
currently being read or written.
On Windows the file system forbids this, so we must be
more careful when deleting and renaming files. These
operations come up a lot internally in the cache:
- deleting to evict an entry
- renaming to commit a dirty file to a clean file
The workaround is simple if unsatisfying: we don't
permit concurrent reads and writes on Windows. We
can have multiple concurrent reders, or a single
writer.
One challenge in this implementation is detecting
whether we're running on Windows or a good operating
system. We deliberately don't look at System properties
here because the OS and file system may disagree, such
as when a Windows machine has an ext4 partition, or when
a Linux machine has an NTFS partition. Instead of detecting
we just attempt an edit and see what happens.
Another challenge in this implementation is what to
do when a file needs to be deleted but cannot be because
it is currently open. In such cases we now mark the
cache entry as a 'zombie'. When the files are later
closed they now check for zombie status and delete the
files if necessary. Note that it is not possible to
store a new cache entry while it is a zombie.
Closes: https://github.com/square/okhttp/issues/5761
From the project's release notes:
Defects Fixed
DLExternal would encode using DER encoding for tagged SETs. This has been fixed.
ChaCha20Poly1305 could fail for large (>~2GB) files. This has been fixed.
ChaCha20Poly1305 could fail for small updates when used via the provider. This has been fixed.
Properties.getPropertyValue could ignore system property when other local overrides set. This has been fixed.
The entropy gathering thread was not running in daemon mode, meaning there could be a delay in an application shutting down due to it. This has been fixed.
A recent change in Java 11 could cause an exception with the BC Provider's implementation of PSS. This has been fixed.
BCJSSE: TrustManager now tolerates having no trusted certificates.
BCJSSE: Choice of credentials and signing algorithm now respect the peer's signature_algorithms extension properly.
BCJSSE: KeyManager for KeyStoreBuilderParameters no longer leaks memory.
Additional Features and Functionality
LMS and HSS (RFC 8554) support has been added to the low level library and the PQC provider.
SipHash128 support has been added to the low level library and the JCE provider.
BCJSSE: BC API now supports explicitly specifying the session to resume.
BCJSSE: Ed25519, Ed448 are now supported when TLS 1.2 or higher is negotiated (except in FIPS mode).
BCJSSE: Added support for extended_master_secret system properties: jdk.tls.allowLegacyMasterSecret, jdk.tls.allowLegacyResumption, jdk.tls.useExtendedMasterSecret .
BCJSSE: Ed25519, Ed448 are now supported when TLS 1.2 or higher is negotiated (except in FIPS mode).
BCJSSE: KeyManager and TrustManager now check algorithm constraints for keys and certificate chains.
BCJSSE: KeyManager selection of server credentials now prefers matching SNI hostname (if any).
BCJSSE: KeyManager may now fallback to imperfect credentials (expired, SNI mismatch).
BCJSSE: Client-side OCSP stapling support (beta version: via status_request extension only, provides jdk.tls.client.enableStatusRequestExtension, and requires CertPathBuilder support).
TLS: DSA in JcaTlsCrypto now falls back to stream signing to work around NoneWithDSA limitations in default provider.
https://www.bouncycastle.org/releasenotes.html
