Make asset links protocol free (so I can get https working)

Having a similar issue. When Drupal aggregates our css it uses http:// for absolute path for images breaking even core images.

Thank you very much, this patch also solved the problem for me that assets (fonts, icons, ...) were no being loaded over https even when the checkbox for "Always serve files from S3 via HTTPS" was set.

Hi guys,

The problem is your Drupal generate http absolute urls, but your site works throught https?

@jansete - Yes. We are using S3 and Drupal aggregation is generating http absolute links in aggregated css files instead of https when the server is configured specifically for https.

@realityloop - No, the patch did not resolve our problem. Not sure if my problem is the same as your problem at this point.

Update on the patch. We've figured out some of our other infrastructure issues and the patch does appear to be working for us.

Sorry guys, but I have tested without patch and is working for me. Are yo sure that your settings configuration is valid?

If you use proxy cache like varnish you must configure in settings.php that you have it.

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = ['127.0.0.1']; // Your reverse proxy IP

If I delete my reverse_proxy settings, all files fails like your cases.

Please review your configuration, because if is this problem you also have the problem in a lot of more places: metatags urls, absolute url links, etc.

Let me know your news.

Greetings!

Not running varnish. We're running S3 on an Elastic Bean Stalk EC2 instance. A reverse proxy doesn't work in that situation as the assets are not stored on the host machine but in a separate bucket.

Then:

Your site run by https in EC2 instance.
Your assets files are in S3 configured to serve by https.
Links in the assets files are by http instead https? (Error solved by the patch)

right?

any updates?

@jansete no, we still can't get it to work without the patch, but then we don't have a dedicated devop anymore, so I might have to go in and fiddle with the server myself. Not that I'm not capable, but I am a bit rusty.

I'm also facing this issue intermittenly. Is there anybody knows in which scenrio it is generating as http instead https?

I confirm that we are facing the very same problem here, Drupal behind a ssl-offloading proxy and with all needed variables to make it aware of that that are working fine for all other scenarios, here is failing and the autogenerated css containts the absolute path in http.

```
$settings['reverse_proxy'] = true;
$reverse_proxy_address = getenv('PROXY_REVERSE_PROXY_ADDRESS') ?
getenv('PROXY_REVERSE_PROXY_ADDRESS') : $_SERVER['REMOTE_ADDR'];
$settings['reverse_proxy_addresses'] = array($reverse_proxy_address);
$settings['reverse_proxy_proto_header'] = 'X_FORWARDED_PROTO';
$settings['reverse_proxy_port_header'] = 'X_FORWARDED_PORT';
```

Applying this patch the protocol gets stripped out and everything is working fine, but this is just a workaround, would be nice to understand at first place why we are changing the default D8 behaviour which just print relative URLs and why anyway it doesn't take in charge the reverse proxy variables.

Sorry guys, but it doesn't convince me, if your site is running over http and you have external resources like images in your css that only works by https, it wouldn't work.

I keep on thinking that is a miss configuration in the servers an reverse proxy in Drupal.

I can also confirm that I'm having issues here.

We're running on AWS Elastic Beanstalk behind an application load balancer that does TLS termination, and using S3FS for public and private file serving. Here's our S3FS module settings (from `settings.php`):

/****************************************************
 *               S3FS module settings.              *
 ****************************************************/
# Same setting for all environments.
$config['s3fs.settings']['bucket'] = getenv('S3FS_BUCKET');
$config['s3fs.settings']['no_rewrite_cssjs'] = TRUE;
$config['s3fs.settings']['public_folder'] = 'public'; // Your public directory in S3
$config['s3fs.settings']['region'] = getenv('S3FS_REGION');
$config['s3fs.settings']['use_https'] = TRUE;
$config['s3fs.settings']['use_instance_profile'] = FALSE;
$settings['s3fs.access_key'] = getenv('S3FS_ACCESS_KEY');
$settings['s3fs.secret_key'] = getenv('S3FS_SECRET_KEY');
$settings['s3fs.use_s3_for_private'] = TRUE;
$settings['s3fs.use_s3_for_public'] = TRUE;

And here's our reverse proxy settings, same file:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' && $_SERVER['REQUEST_SCHEME'] == 'http') {
  $_SERVER['HTTPS'] = 'on';
  $settings['reverse_proxy'] = TRUE;
  $settings['reverse_proxy_trusted_headers'] = Request::HEADER_X_FORWARDED_AWS_ELB;
  $settings['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];
  $config['system.performance']['css']['preprocess'] = FALSE;
}

With aggregation enabled for CSS, I get errors like:

modernizr.min.js?v=3.3.1:3 Mixed Content: The page at 'https://[domain]/' was loaded over HTTPS, but requested an insecure font 'http://[domain]/themes/custom/[subtheme]/fonts/opificio/Opificio_Bold.woff'. This request has been blocked; the content must be served over HTTPS.

Looking at the aggregated CSS file, I'm seeing output like:

url(http://[domain]/themes/custom/[subtheme]/fonts/opificio/Opificio_bold.woff)

We're also seeing this for core file requests:

Mixed Content: The page at 'https://[domain]/' was loaded over HTTPS, but requested an insecure image 'http://[domain]/core/misc/icons/bebebe/hamburger.svg'. This content should also be served over HTTPS.

When I disable CSS aggregation in the site, these errors go away.

The patch #2 worked perfectly fine for us.
Thanks

As a workaround, If you have configured varnish or CDN and your prod site is running on two different domain like http://prod.xyz.com and https://xyz.com then you can write a regex as mentioned in the patch.

s3fs/src/Asset/S3fsCssOptimizer.php

$path = file_create_url($path);
$path = preg_replace('/prod\./', '', $path);
$path = preg_replace('/^http:/', 'https:', $path);
return 'url(' . $path . ')';

Sticking this here as a reminder as I was almost about to say that I couldn't duplicate this when I managed to get replicate it.

What I think I just saw from a quick test is with S3FS managing public that the link will depend based on if a first request was to an HTTP page or an HTTPS page.

Checking with S3FS off I notice that the same CSS file is used for HTTP and HTTPS pages which matches what I see with S3FS on, which corresponds to the problem.

Checking the CSS files with S3FS off the urls are being generated as ':url(/core/misc/icons/000000/chevron-right.svg)' while with S3FS we are indeed generating them with the protocol and full hyperlink.

Looks like this might have something to do with advagg based on the previous commit references #2851907: Bad image references when css is minified so I will need to dig into that a bit more.

Tested stock Drupal 9.1 no changes to CSS implemented.

Ok I'm pretty sure I see what is going on here.

If using the proxy method of '/s3fs-js/' and '/s3fs-css/' there is no need to rewrite the URL's as they will be relative to the server root and work great for HTTP/HTTPS.

However if one unchecks 'Don't rewrite CSS/JS file paths' (which is noted to only do if you need it) than we have a problem, the files are served from bucket.s3.amazon.aws.com/ and the relative paths now refer to the files being on S3. I suspect that was the issue attempting to be solved in #2851907: Bad image references when css is minified

Judging by the comments I'm seeing in similar threads It doesn't appear we can get the CSS to be rendered as different files on a page based on if it is HTTP/HTTPS causing the mismatch.

So when we are re-writing the path to css/js files we should use relative paths which can be accomplished by not registering the interceptors.

The question that I could use some feedback on is do we always need the internal content rewrite on 'Don't rewrite CSS/JS file paths' since the CSS will always be on S3 or are there some modules that already intercept the request, change the URLs to be full URLS and we need to make sure we don't interfere with those changes?

Not knowing the answer to the second part I'm thinking I need two additional options available when 'Don't rewrite CSS/JS file paths' is checked:

• "Don't rewrite paths inside CSS/JS files" to prevent changing them should a 3rd party module need to make changes.
• "Disable force https rewrites" where we instead of making the links without a protocol we always use HTTPS unless disabled in which case fall back to the current method of determine protocol based on the first person to load the page. (basically this checkbox would allow for HTTP only sites but useless for pages via http/https)"

The code flow basically being:

If files are to be access via the s3fs proxy paths:
  Do not rewrite content inside the css/js files.
Otherwise:
  If configured to rewrite content inside the files:
    By default rewrite URLS with https://basedomain
      Unless instructed to use the protocol of the first person to load a page that uses this file in which case use that protocol.
  Otherwise:
   Don't touch the internals of the files

On quick glance I believe we can do all this (minus the actual form portion) in S3fsServiceProvider.

Went a slightly different method than previously described.

All links will be rewritten when using the public:// service.

Added an ability to select a custom hostname for the links inside of CSS/JS files (useful for when you use a CDN for static content with your Drupal server).

Links will default with '//servername/path' format to allow protocal agnostic use. However it is recommended to check 'use_https' if your servers support it it as '//servername' is a bit of an anti-pattern and could cause some issues when content get copied into other systems such as email.

Opened #3201395: #2948554 no upgrade path. There is a regression for config as there isn't an update path provided with the fixes from this issue.