Milo and EDS link transformation - Bacom link typo http vs https

[JasonHowellSlavin]

Hello community,

During a release our authors accidentally added links with http instead of https. Because of the way Milo and EDS process links, this slipped through both Preflight and preview for our authors, and links with http leading to preview content made it to production.

However, I think we can prevent this issue by updating our localizeLink function to no longer "process" links to make them relative. After we do this, I have been asked to add a check for HTTP to Preflight, and Preflight could catch the issue.

First, it appears that EDS already localizes links based on the origin, as seen in this page source:

You can see that the fragments, etc. all are localized. If you compare with this screenshot:

On line 88 you can see that a url with a /fragment/ path was made relative even though authored with an origin, but the link after it in the span, https://business.adobe.com was not made relative. The fragment is authored with a hlx.page url, the b.a.com url is authored as a fully qualified b.a.com url and is not made relative by EDS.

The bug occurred for our authors because when we run localizeLink, Milo checks by hostname and then if it finds the hostnames are the same it removes all but the path. However, checking by hostname omits HTTP|S which caused our bug. It also seems to me that it may be redundant as EDS makes links relative as well. As far as I can tell, EDS checks for EDS origins including the HTTPS (EDS seems to make relative both page and live links regardless of which environment you are viewing).

When our authors were authoring the pages, they were previewing on hlx.page, and because the hostname matched, Milo made the link with HTTP relative, showing no issue. However, when moving to production, the hostname and origins did not match, so EDS and Milo did not modify the links, making it so that HTTP links were on the production pages.

Can we remove the code that modifies the link? Is there a reason why we make links with matching hostnames relative when EDS does so if the origin matches? If we could remove it, that block of code could be simplified greatly I think.

[JasonHowellSlavin]

Hi @mokimo , @overmyheadandbody, and @janaki-r-bhagwath would love your thoughts on the above!

Thank you,
Jason

[mokimo]

I don't have any context of why we do this, but context on links in general...

EDS turns all links into relative ones, however we do alter some links, for specific use-cases. To my mind come links using 'federal' where we never want a relative but a fully qualified link to consume the centralized content.

I'm generally a bit cautious about changing this logic, because it will lead to a long tail of issues and I'm 99% sure of this, because most of this logic is there for some use-case.... However, we always happily accept PRs 😁

@robert-bogos do you have any feedback, considering you lately shipped a bigger feature for link transformation looking at various use-cases?

[robert-bogos]

@JasonHowellSlavin My take on this would to be to solve it by adding a preflight check for HTTP links.
I'm also reluctant to remove logic from the codebase as is definitely in there for a reason.

[JasonHowellSlavin]

Hi @robert-bogos I did add a preflight check for HTTP links in Preflight: https://main--bacom--adobecom.hlx.live/drafts/slavin/rtcdp?milolibs=add-http-check-to-preflight

It works as expected when an author uses it on a hlx.live page. However, since Preflight runs after link transformation, when the author runs Preflight on a hlx.page page, the link is made relative by Milo. Our stakeholder stated that they almost exclusively use it on .page.

Perhaps the answer is additive? I could add a line of code somewhere in our link transformation chain to add a class or a data attribute to links with http, and have preflight highlight those?

[vhargrave]

@JasonHowellSlavin I think that's a good approach 👍 .