- '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':

 * 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,...

  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

 - 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

- 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), ...

   * was GET or HEAD.
   *
   * In OkHttp 4.6 and later, HTTP 307 and 308 redirects are honored for all request methods.
   *
   * If you're upgrading to OkHttp 4.6 and would like to retain the previous behavior, install this
   * as a **network interceptor**. It will strip the `Location` header of impacted responses to
   * prevent the redirect.
   *
   * ```