You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains 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
This package is not super maintained and quite annoying to work with, particularly when we need to serve a static deployment under a baseUrl.
We can't do a rewrite from /baseUrl/:path to /:path, all requests end up as 404. I think the destination path must be an existing HTML files, not just a pathname.
Historically we have worked around that limitation thanks to the following hack:
// Remove baseUrl before calling serveHandler, because /baseUrl/ should// serve /build/index.html, not /build/baseUrl/index.html (does not exist)req.url=req.url.replace(baseUrl,'/');
But the problem is that when the server handler is called with a trailingSlash: false setting for example, the responses will redirect /baseUrl/xyz/ to /xyz instead of /baseUrl/xyz. And the lib calls res.end() so there's no way to properly re-integrate that baseUrl to the redirect Location header.
So, this fix applies another workaround on top of serve-handler, so that we can avoid incorrect "trailing slash redirects" from serve-handler.
Test Plan
It's hard to test this automatically 😅 but I tested this locally under various scenarios
We can't do a rewrite from /baseUrl/:path to /:path, all requests end up as 404. I think the destination path must be an existing HTML files, not just a pathname.
I'm afraid that serve command failed to serve static files like 'index.js' with trailingSlash: true since it will always redirect to a 404 page.
@msyfls123 if you think there's a bug please create a docusaurus.new repro with clear instructions on how to see the wrong behavior happening, and what is the expected behavior
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.
Motivation
Fix #10078
docusaurus serve
depends on vercel/serve-handlerThis package is not super maintained and quite annoying to work with, particularly when we need to serve a static deployment under a baseUrl.
We can't do a rewrite from
/baseUrl/:path
to/:path
, all requests end up as 404. I think the destination path must be an existing HTML files, not just a pathname.Historically we have worked around that limitation thanks to the following hack:
But the problem is that when the server handler is called with a
trailingSlash: false
setting for example, the responses will redirect/baseUrl/xyz/
to/xyz
instead of/baseUrl/xyz
. And the lib callsres.end()
so there's no way to properly re-integrate that baseUrl to the redirect Location header.So, this fix applies another workaround on top of serve-handler, so that we can avoid incorrect "trailing slash redirects" from serve-handler.
Test Plan
It's hard to test this automatically 😅 but I tested this locally under various scenarios