Add client-side fallback for trailing-slash mismatches - #719
Open
louisachu wants to merge 2 commits into
Open
Conversation
EDS treats a folder-index page and a direct-file page as distinct resources based on the trailing slash, unlike Gatsby which tolerated either form. External links/bookmarks predating the migration often use the wrong form and 404 even though the page exists under the other form. The connector (devsite-runtime-connector) already returns a real 301 for this case, but Helix's content-bus integration discards non-200 responses from custom content sources and substitutes its own generic 404, so the redirect never reaches real users. This client-side fallback checks, from the 404 page, whether the sibling slash-form resolves and redirects there if so - it runs after the curated redirects.json lookup so intentional page-move redirects still take priority.
|
❌ Test ResultsStatus: Some tests failed! 🔍 Click to view failed testsTest Coverage ReportOverall Coverage Summary
Coverage by File/Directory
Coverage report generated at 2026-08-06T00:08:33.053Z |
| async function redirectOnTrailingSlashMismatch() { | ||
| const candidate = toggleTrailingSlash(window.location.pathname); | ||
| const resp = await fetch(candidate); | ||
| if (resp.ok) { |
There was a problem hiding this comment.
const resp = await fetch(candidate, { method: 'HEAD' }); can we do this instead of GET since only resp.ok is read and the body is never used.
priyajeettanwar
left a comment
priyajeettanwar
left a comment
There was a problem hiding this comment.
@louisachu While I understand this is a client-side fix, I think the long-term fix should be in EDS/Helix.
As you mentioned in the PR, the devsite-runtime-connector already returns a proper 301, but Helix's content-bus discards non-200 responses from custom content sources and replaces them with a generic 404, so the redirect never reaches users.
The current approach works as a short-term workaround, but I think we should also push for an EDS/Helix fix so the original HTTP responses are preserved.
Only resp.ok is read, so HEAD avoids downloading the full page body on every 404 hit while still guaranteeing the same status code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
EDS treats a folder-index page and a direct-file page as distinct resources based on the trailing slash, unlike Gatsby which tolerated either form. External links/bookmarks predating the migration often use the wrong form and 404 even though the page exists under the other form.
The connector (devsite-runtime-connector) already returns a real 301 for this case, but Helix's content-bus integration discards non-200 responses from custom content sources and substitutes its own generic 404, so the redirect never reaches real users. This client-side fallback checks, from the 404 page, whether the sibling slash-form resolves and redirects there if so - it runs after the curated redirects.json lookup so intentional page-move redirects still take priority.
Before:
https://stage--adp-devsite-stage--adobedocs.aem.page/dev-docs-reference/blocks/table
Now:
https://devsite-2506-test--adp-devsite-stage--adobedocs.aem.page/dev-docs-reference/blocks/table will redirect to
https://devsite-2506-test--adp-devsite-stage--adobedocs.aem.page/dev-docs-reference/blocks/table/
bug:
https://jira.corp.adobe.com/browse/DEVSITE-2506