Ability to force using a scheme instead of scheme-relative URLs
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #2925819. -->
Reported by: [wim leers](https://www.drupal.org/user/99777)
>>>
<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/cdn/-/work_items/2840757" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/cdn/-/work_items/2840757</a></span> described how the CDN module's use of protocol-relative URLs causes</p>
<ol>
<li>problems with the metatag module due to bugs in that module, for which we have <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/metatag/issues/2840751" title="Status: Closed (fixed)">#2840751: Protocol-relative URLs are broken</a></span> and <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-3"><a href="https://www.drupal.org/project/metatag/issues/2867742" title="Status: Closed (duplicate)">#2867742: Interaction with CDN module</a></span></li>
<li><a href="https://twittercommunity.com/t/domain-whitelisted-for-summary-large-image-card-but-image-not-showing-in-the-validator/30722">problems with the Twitter Card API, because it only supports absolute URLs</a>.</li>
</ol>
<p>Even though that second point is unquestionably a bug in Twitter's code, the reality is that they still haven't fixed it after years. So we need to find another way to fix it.</p>
<p>Additionally, there are other cases where protocol-relative URLs aren't allowed:</p>
<ul>
<li>RSS feed "enclosure" elements, as used in podcast feeds</li>
<li>Facebook's use of the "og:image" metatag to determine which image to attach to a social share</li>
</ul>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>If the CDN module would be able to tell with absolute certainty that A) the origin used only HTTPS, B) all CDNs it uses to serve static files also support HTTPS, then the CDN module would be able to use absolute HTTPS URLs rather than protocol-relative URLs.</p>
<p>Unfortunately, there's no way to know this for certain. There's nothing in <code>settings.php</code>, <code>Settings</code> or in configuration that indicates or enforces this. This is exactly why the CDN module today works like it does: it does the prudent thing, the thing that works always, which is using protocol-relative URLs. <em>The only place where this breaks down (hitherto known), is Twitter Cards <code><meta></code> tags.</em></p>
<p><strong>If we'd have a very-high-probability indicator that a site was HTTPS-only, then we could make the CDN module use absolute HTTPS URLs automatically. I think I may have found that indicator: if a site has the <a href="https://drupal.org/project/hsts">https://drupal.org/project/hsts</a> module installed, this probability is extremely high.</strong></p>
<h3 id="summary-remaining-tasks">Remaining tasks</h3>
<p>None.</p>
<h3 id="summary-ui-changes">User interface changes</h3>
<p>The UI gains an additional dropdown in the "mapping" vertical tab, to configure the scheme to use:<br>
<img src="https://www.drupal.org/files/issues/2019-12-12/cdn-2925819-50.png" alt=""><br>
<img src="https://www.drupal.org/files/issues/2019-12-12/Screenshot%202019-12-12%20at%2016.18.41.png" alt=""></p>
<h3 id="summary-api-changes">API changes</h3>
<p>None.</p>
<h3 id="summary-data-model-changes">Data model changes</h3>
<p>A new <code>scheme</code> key in the <code>cdn.settings</code> configuration.</p>
> Related issue: [Issue #2840751](https://www.drupal.org/node/2840751)
> Related issue: [Issue #2867742](https://www.drupal.org/node/2867742)
> Related issue: [Issue #2925974](https://www.drupal.org/node/2925974)
> Related issue: [Issue #88183](https://www.drupal.org/node/88183)
> Related issue: [Issue #2704597](https://www.drupal.org/node/2704597)
> Related issue: [Issue #2669074](https://www.drupal.org/node/2669074)
issue