URI rewriter thinks protocol agnostic URIs like //fonts.googleapis.com are internal

[lkraav]

This is crucial, because Firefox 23 actively blocks mixed content, leading to decidedly bad UX.

Try enqueueing something like "//fonts.googleapis.com/css?family=Lato:300,400|Open+Sans:300".

Dep. Minification admin panel will be filled with errors "Request for http://domain.com//fonts.googleapis.com/css?family=Lato:300,400 returned with HTTP 404 Not Found Try again"

[westonruter]

Yes, excellent. I ran into this issue myself and had to force the protocol to be added each time. It shouldn't be too difficult to fix, and from looking at the code I'm not sure why this is happening. I think the problem is happening here:

$has_host = (bool) parse_url( $src, PHP_URL_HOST );
if ( ! $has_host ) {
    $src = 'http://' . $host_domain . $src;
}

However, it seems that parse_url is properly detecting scheme-less URLs:

wp> parse_url( '//example.com/foo/bar', PHP_URL_HOST )
string(11) "example.com"

Oh, I see what the problem is. Looking at the parse_url docs:

5.4.7 Fixed host recognition when scheme is omitted and a leading component separator is present.

So to be compatible with PHP<5.4.7, we need to make the $has_host condition something like:

$has_host = ( (bool) parse_url( $src, PHP_URL_HOST ) || strpos( $src, '//' ) === 0 )

[lkraav]

I'm going to test this approach

[lkraav]

It appears is_self_hosted_src() also requires help.

[lkraav]

Adding the same

if ( strpos( $src, '//' ) === 0 ) return false;

in front of existing is_self_hosted_src() logic seems to stop the plugin from coughing blood.

[lkraav]

Since WPEngine is known to lag behind time with their 5.3 thing, I'm going to try to address this with a pull request.