How to flush cookies as of PHP8

[divinity76]

Prior to php8, curl_close($ch) would flush the cookie list. Code that depend on the cookie list to be flushed on curl_close() breaks on PHP8. Document an alternative way to flush the cookie list: curl_setopt($ch, CURLOPT_COOKIELIST, "FLUSH");

Resolves #2239

[Copilot]

Pull request overview

Updates the curl_close() documentation to address a behavioral change in PHP 8+ where curl_close() no longer destroys the handle (and therefore no longer triggers cookie persistence implicitly), and to document an explicit way to flush cookies.

Changes:

• Add a note to curl_close() docs describing how to flush cookies via CURLOPT_COOKIELIST "FLUSH".
• Minor whitespace/formatting cleanup in the XML.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[divinity76]

related to #2239

[nrps9909]

Approved exact head 884c31ad27aa3c8ffddc1c46d0f6cba93e6fbccd.

The added migration note matches the underlying libcurl contract: CURLOPT_COOKIELIST with "FLUSH" writes all known cookies to the file configured through CURLOPT_COOKIEJAR. It also puts that recovery path on the curl_close() page, where PHP 8 users who discover that the function is now a no-op are most likely to need it; the more detailed option reference already documents the same operation.

I checked the exact diff against the current option documentation and libcurl's official CURLOPT_COOKIELIST reference. The current exact-head Build (en) and DocBook Style Check (en) jobs are both green, and git diff --check passes locally.

AI assistance disclosure: Codex was used to inspect the exact-head XML and repository guidance, compare the related PHP documentation, verify the libcurl semantics, audit live CI, and draft this review. I verified the cited SHA and results before approving.

[nrps9909]

Clarification on my review above: GitHub does not allow me to submit an APPROVED review without explicit repository access, so its actual state is COMMENTED. “Approved exact head” there means I found no blocking issue in the cited SHA; it is not a maintainer approval. The semantic and CI evidence in the review is unchanged.