- 'Works with OkHttp': works_with_okhttp.md
  - 'API': 5.x/okhttp/okhttp3/
  - 'Change Logs':
    - 'Change Log': changelogs/changelog.md
    - '4.x Change Log': changelogs/changelog_4x.md
    - 'Upgrading to OkHttp 4': changelogs/upgrading_to_okhttp_4.md
    - '3.x Change Log': changelogs/changelog_3x.md
    - '2.x Change Log': changelogs/changelog_2x.md
    - '1.x Change Log': changelogs/changelog_1x.md
  - 'Contributing':

- ACTION REQUIRED:
  

 * Use [Builder.allEnabledTlsVersions] and [Builder.allEnabledCipherSuites] to defer all feature
 * selection to the underlying SSL socket.
 *
 * The configuration of each spec changes with each OkHttp release. This is annoying: upgrading
 * your OkHttp library can break connectivity to certain web servers! But it’s a necessary annoyance
 * because the TLS ecosystem is dynamic and staying up to date is necessary to stay secure. See

    - [SIG Node](#sig-node)
    - [SIG Network](#sig-network)
    - [SIG Scalability](#sig-scalability)
    - [SIG Scheduling](#sig-scheduling)
    - [SIG Storage](#sig-storage)
  - [Before Upgrading](#before-upgrading)
  - [Known Issues](#known-issues)
  - [Deprecations](#deprecations)
    - [Apps](#apps)
    - [Auth](#auth)
    - [Autoscaling](#autoscaling)
    - [Cluster Lifecycle](#cluster-lifecycle)

    who read the trailers on the `raw()` OkHttp response, after its body was decoded.


## Version 5.0.0

_2025-07-02_

This is our first stable release of OkHttp since 2023. Here's the highlights if you're upgrading
from OkHttp 4.x:

**OkHttp is now packaged as separate JVM and Android artifacts.** This allows us to offer
platform-specific features and optimizations. If your build system handles [Gradle module metadata],

dynamic resources to Pods.

  if and only if classic DRA was enabled in a cluster, remove all workloads (pods, app deployments, etc. ) which depend on classic DRA and make sure that all PodSchedulingContext resources are gone before upgrading. PodSchedulingContext resources cannot be removed through the apiserver after an upgrade and workloads would not work properly. ([#128003](https://github.com/kubernetes/kubernetes/pull/128003), [@pohly](https://github.com/pohly)) [SIG API Machinery,...

 - Reduced state change noise when volume expansion fails. Also mark certain failures as infeasible.
  
  ACTION REQUIRED:  If you are using the `RecoverVolumeExpansionFailure` alpha feature gate
  then after upgrading to this release, you need to update some objects.
  For any existing PersistentVolumeClaimss with `status.allocatedResourceStatus` set to either

  The `flowcontrol.apiserver.k8s.io/v1beta3` APIs are deprecated and will no longer be served in v1.32. All existing objects are available via the `v1` APIs. Transition clients and manifests to use the `v1` APIs before upgrading to `v1.32`. ([#121089](https://github.com/kubernetes/kubernetes/pull/121089), [@tkashem](https://github.com/tkashem))
- The `kube-proxy` command-line documentation was updated to clarify that

  to kubelet config ([#112136](https://github.com/kubernetes/kubernetes/pull/112136), [@pacoxu](https://github.com/pacoxu))
- `resource.k8s.io/v1alpha1` was replaced with `resource.k8s.io/v1alpha2`. Before
  upgrading a cluster, all objects in resource.k8s.io/v1alpha1 (ResourceClaim, ResourceClaimTemplate,
  ResourceClass, PodScheduling) must be deleted. The changes are internal, so

- VSphere releases less than 7.0u2 are not supported for in-tree vSphere volume  as of Kubernetes v1.25. Please consider upgrading vSphere (both ESXi and vCenter)  to 7.0u2 or above. ([#111255](https://github.com/kubernetes/kubernetes/pull/111255), ...