Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
The link rel="alternate" response headers were removed in #2873648: With many languages, content_translation_page_attachments adds too many alternate links to the response headers crashing varnish (503)
The HTTP Link entity-header field provides a means for serializing one or more links in HTTP headers. It is semantically equivalent to the HTML
element.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link
The first bytes in a response are important from a performance perspective. If Link response headers are semantically equivalent to the HTML <link> element, these links should not be available in both the response headers and HTML <link> elements
Apparently Google added support for this to there search engine indexing in 2011. I think the primary use-case was for
giving webmasters yet another avenue to provide a preferred URL for non-text/html content-types such as PDF files
Source: https://moz.com/blog/how-to-advanced-relcanonical-http-headers
Because it’s relatively easy to implement rel=canonical tags in a page’s HTML, it’s rare to find canonical links sent as part of a page’s HTTP response. However, it’s always worth double-checking the page’s HTTP headers for canonical links, especially if you see unusual indexing and ranking issues on a website.
Source: https://searchengineland.com/the-ultimate-guide-to-http-status-codes-and...
Proposed resolution
Remove redundant Link canonical/shortlink response headers
Remaining tasks
- Write a patch
- Review
- Commit
User interface changes
None.
API changes
None.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3266589-5.patch | 1.93 KB | idebr |
| |||
Issue fork drupal-3266589
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
idebr CreditAttribution: idebr at iO commentedComment #3
idebr CreditAttribution: idebr at iO commentedAttached patch removes redundant Link canonical/shortlink response headers
Comment #4
Wim Leers0 byte patch 🤓
Comment #5
idebr CreditAttribution: idebr at iO commentedAttached patch has bytes and removes redundant Link canonical/shortlink response headers
Comment #6
mfbAdded draft change record @ https://www.drupal.org/node/3267018
Comment #7
longwaveJust spotted this in a site I am debugging that has a large number of HTTP headers, agree that these are duplicated with
<link>tags and so should be removed.Comment #9
catchAgreed these are redundant, and it makes more sense to send them as part of the response body than the headers.
Committed/pushed to 10.1.x, cherry-picked to 10.0.x and 9.5.x, thanks!
Comment #10
longwaveComment #11
xjmThe release note could use some work to answer the question "What does this mean to me?" for a site owner or module developer. The release note should describe what it was before, what changed, what the consequences of the change are, and what a site owner or module developer might need to do as a result. It should also link the change record. Thanks!
Comment #12
catchI've added a sentence, which says that it should have no effect at all + linked the change record, agreed it's good to spell that out.
Comment #13
xjmIf it has no effect at all, why would it need to be in the release notes?
Comment #14
catchYeah that's a fair point. There's an infinitesmal chance that someone has a custom bot somewhere that reads the headers and not the HTML head, but there's no reason to write something like that, and it's not anything that site owners could do anything about anyway. Untagging and removing the release note. We can keep the CR.