[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