Instagram oEmbed not working with Requests_Transport_fsockopen

[MrGregWaugh]

When using Requests_Transport_fsockopen as the default Requests transport (say cURL is not available or disabled), Instagram oEmbeds / Embeds fail.

I did some digging and the issue comes down to an acknowledged issue in proxygen (used by at least Instagram's API), and is referenced here (from 2015):

​https://github.com/facebook/proxygen/issues/47

The difference between it working with Requests_Transport_cURL and not with Requests_Transport_fsockopen comes down to the Host: header adding the port number while using HTTPS.

Curl:

Host: api.instagram.com

fsockopen:

Host: api.instagram.com:443

If a port number is present (like fsockopen), Instagram's API will return "400 Bad Request".

RFC 2616 states:

A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL).

This would imply that it is optional as long as it us using the default port for the service (80 for http, 443 for https), however it's clear that proxygen will not work if port is included in the Host: header.

While this would seem to show that this is an issue with proxygen, the reason I am reporting it here is that the behavior in Requests is inconsistent between the two transports -- these pluggable transports should function as close to in-parity as possible. Also, the effect is that the WP Instagram oEmbed feature is broken for non-cURL systems until one side makes a change.

The request/bug report is to examine behavior of all available transports and make them behave the same OR come up with a workaround/filter/option to modify this behavior at runtime if necessary to work around known-broken providers.

Steps to reproduce:

1. Disable cURL extension on WP instance.
2. Open Visual editor and paste in an Instagram link.

Many thanks.

[dd32]

Thanks for raising this @MrGregWaugh! However, we're already tracking this over in #37991 and it should be fixed upstream.