wp_remote_retrieve_headers no longer an array in WordPress 4.6

[jstkrn]

With the introduction of Requests in PHP 4.6, headers are returned as a Requests_Utility_CaseInsensitiveDictionary object instead of a native PHP array, see wp-includes/class-wp-http-requests-response.php > get_headers. Although this object implements ArrayAccess, it technically is no longer an array and this causes a plugin of mine to break due to incompatible types, as I assert that an array is given.

Documentation and docblocks needs to be updated to reflect this change.

[swissspidy]

Previously, there was the same issue with responses, see [37989]. We should be consistent with return types, so I'd consider this a bug.

[jstkrn]

Replying to swissspidy:

Previously, there was the same issue with responses, see [37989]. We should be consistent with return types, so I'd consider this a bug.

This is indeed likely to break some more plugins, given that typehints fail and is_array now returns false, but I also embrace changes such as the introduction of Requests and headers now being case-insensitive is a nice feature. Hence the suggestion to keep the current implementation and updating the docs (although that may not fit with WordPress's compatibility policy, I wouldn't know)

[dd32]

Previously, there was the same issue with responses, see [37989]. We should be consistent with return types, so I'd consider this a bug.

We only really changed the return type for the main request object due to the number of plugins who would assume !is_array() was a failed HTTP request, even though that was a bad habit to be in.

We saw that this may also have the same issue, however deliberately chose to break this not-really-supported scenario, the benefits of the case insensitive dictionary are worth it, and we I don't think we could easily present the original-cased headers anyway.

As such, I consider this a documentation update, which doesn't need to be in 4.6.1 (unless someone else feels it should be)

[swissspidy]

@dd32 Thanks for your input. I'm fine with anything that doesn't need to be in 4.6.1 :-) Can always reconsider of course if it turns out to be a bigger problem.

[jorbin]

Improving the documentation could be a good first bug.

[mrahmadawais]

FIX: DocBlock return to object instead of headers' array & PHPCS Errors

[mrahmadawais]

Added a patch to fix the docs as well as two minor errors in accordance with PHPCS.

[swissspidy]

@mrahmadawais Thanks for the patch! It would be great if the exact object type (Requests_Utility_CaseInsensitiveDictionary) could be noted in the doc block instead of simply object.

Not sure if we need a @since 4.6.0 return value changed […] entry.

[mrahmadawais]

FIX: DocBlock return to object instead of headers' array & PHPCS Errors

[mrahmadawais]

Replying to swissspidy:

@mrahmadawais Thanks for the patch! It would be great if the exact object type (Requests_Utility_CaseInsensitiveDictionary) could be noted in the doc block instead of simply object.

Fixed that in the second patch.

Not sure if we need a @since 4.6.0 return value changed […] entry.

Lost you here, what are you talking about?

[swissspidy]

Replying to mrahmadawais:

Replying to swissspidy:

@mrahmadawais Thanks for the patch! It would be great if the exact object type (Requests_Utility_CaseInsensitiveDictionary) could be noted in the doc block instead of simply object.

Fixed that in the second patch.

Not sure if we need a @since 4.6.0 return value changed […] entry.

Lost you here, what are you talking about?

I was thinking if we need to add a note to inform developers that the return type changed.

[sudar]

Made the following changes to the patch

• Added a note that return value got changed in v4.7.0
• Tweaked the return value to reflect the class name.

[dd32]

In 38730:

HTTP: Document that the return value of wp_remote_retrieve_headers() changed from a simple array to an object which implements ArrayAccess.

Props mrahmadawais, sudar, swissspidy.
Fixes #37722