`CURLINFO_HEADER_OUT` is "defined" twice in the manual
This can give false positives about a constant having incorrect linking.
Not sure how to handle the markup that you created @Ayesh, do you have any ideas/opinions @haszi?
CURLINFO_HEADER_OUT isn't a Curl option, but we were using it for ages now (with a custom debug handler to catch and store the output headers). All use cases for this constant in existing documents should be referring to the Curl option; not the new use case with the CURLOPT_DEBUGFUNCTION option.
I thought about this when working on #4069, because the context for CURLINFO_HEADER_OUT in the CURLOPT_DEBUGFUNCTION callback is different. So, all references to that constant syntax go like this:
<varlistentry xml:id="constant.curlinfo-header-out-debug">
<term>
<constant linkend="constant.curlinfo-header-out-debug">CURLINFO_HEADER_OUT</constant>
For curl_setopt($ch, CURLINFO_HEADER_OUT) use case, bare <constant>CURLINFO_HEADER_OUT</constant> should continue refer to the old use case. Any documents that want to link to the new CURLINFO_HEADER_OUT constant context can link to it as <constant linkend="constant.curlinfo-header-out-debug">CURLINFO_HEADER_OUT</constant>.
This is unfortunate but I think we can make the markup Ayesh is proposing work in PhD.