[wp-trac] [WordPress Trac] #38163: Instagram oEmbed not working with Requests_Transport_fsockopen
WordPress Trac
noreply at wordpress.org
Mon Sep 26 18:17:45 UTC 2016
#38163: Instagram oEmbed not working with Requests_Transport_fsockopen
--------------------------+-----------------------------
Reporter: MrGregWaugh | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: HTTP API | Version: 4.6.1
Severity: normal | Keywords:
Focuses: |
--------------------------+-----------------------------
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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/38163>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list