pathPrefix and redirects

[YoshiWalsh]

Hi all, I'm a maintainer of gatsby-plugin-s3. One of the long-standing issues with our project has been support for prefixed sites, you can see this in gatsby-uc/gatsby-plugin-s3#24 and gatsby-uc/gatsby-plugin-s3#208. I'm interested in finally solving this once and for all, but I'm running into some philosophical questions about prefixing.

In my view there are two kinds of prefix:

• a client-facing prefix is one that appears in the URL: e.g. https://example.org/**blog/**my-blog-post

• a storage prefix is one that applies to the file system on the server: e.g. /var/www/example.org/**blog/**my-blog-post/index.html

In the simplest case these are both the same. But there are scenarios where you might want to have a storage prefix without any client-facing prefix, such as if you want to store multiple versions of your site and use something like Lambda@Edge to select one for AB testing. Having a client-facing prefix without a storage prefix is also something that's supported by a lot of server software, such as via nginx's location block. Maybe there are even some cases where someone would want to use a different client-facing prefix and storage prefix.

Gatsby's pathPrefix appears to be intended to cater for client-facing prefixes. Output files are placed in public/ without any prefix.
In gatsby-plugin-s3 we provide a plugin option bucketPrefix which allows for specifying a storage prefix.

The issue we are experiencing is that while Gatsby does not prepend pathPrefix to output files, Gatsby does prepend pathPrefix to the fromPath of redirects. This behaviour is covered by tests,

gatsby/packages/gatsby/src/redux/__tests__/redirects.ts

Lines 101 to 109 in 57ca573

	it(`create redirects as permanent`, () => {
	const action = actions.createRedirect({
	fromPath: `/old/hello-world`,
	toPath: `/new/hello-world`,
	isPermanent: true,
	})
	expect(action).toMatchSnapshot()
	})

gatsby/packages/gatsby/src/redux/__tests__/__snapshots__/redirects.ts.snap

Lines 171 to 181 in 57ca573

	exports[`Add redirects with path prefixs create redirects as permanent 1`] = `
	Object {
	"payload": Object {
	"fromPath": "/blog/old/hello-world",
	"isPermanent": true,
	"redirectInBrowser": false,
	"toPath": "/blog/new/hello-world",
	},
	"type": "CREATE_REDIRECT",
	}
	`;

so it appears to be intentional. This inconsistency causes issues for us because we prepend our own bucketPrefix to redirects.

It is my opinion that pathPrefix should be prepended to toPath of redirects, but not to fromPath. For fromPath, the prefixing should be handled by whichever plugin is deploying the redirect.

Another option would be for us to stop prefixing bucketPrefix for redirects and just rely on the pathPrefix instead. But this doesn't work as expected when pathPrefix and bucketPrefix have different values. Consider a case where someone is hosting two versions of their site out of the same bucket, and using Lambda@Edge to serve each one to different clients for AB testing. public/index.html gets uploaded to a/index.html and b/index.html thanks to bucketPrefix, while pathPrefix is left blank so the user still just visits https://example.org/ and not https://example.org/a/. The developer wants to add a redirect on site A. If we don't apply bucketPrefix, the redirect will be pushed to old-page, when the user really wants the redirect pushed to a/old-page.

Please let me know your thoughts.

Thanks,
Josh

[pieh]

Hey @JoshuaWalsh

I think observation you did:

Gatsby's pathPrefix appears to be intended to cater for client-facing prefixes. Output files are placed in public/ without any prefix.

Is pretty spot on. That's pretty much what redirects as they are now in gatsby are meant to do and it really is to cover cases of moving some page to new URL/slug within context of same pathPrefix.

It is my opinion that pathPrefix should be prepended to toPath of redirects, but not to fromPath. For fromPath, the prefixing should be handled by whichever plugin is deploying the redirect.

This is a breaking change, so not sure if we can even consider this. Maybe instead there should be toggle (prefixFromPath: false) available on createRedirect to allow users to opt-out of it or have both fromPath field (which continues to be prefixed) and unprefixedFromPath (original one) and let deploy plugin decide which to use, but I personally am not sure if ultimately would be the path to go ( because createRedirect just wasn't meant for such use cases and the behaviour change might be confusing to users that rely on things as they work today). Lastly deploy plugins could just "strip" path prefix from fromPath themselves.

The developer wants to add a redirect on site A. If we don't apply bucketPrefix, the redirect will be pushed to old-page, when the user really wants the redirect pushed to a/old-page.

I'm struggling a bit with this (in terms of understanding what you mean) - for site visitors they should still see old-page (not a/old-page) in URL, correct? Just the resource on "the server" that is served should be a/old-page?

[YoshiWalsh]

Hi @pieh , thanks for the response.

If there was an originalFromPath which was based on the unmodified value provided to createRedirect, I think that would solve the issue without being likely to break anything.

I'm struggling a bit with this (in terms of understanding what you mean) - for site visitors they should still see old-page (not a/old-page) in URL, correct? Just the resource on "the server" that is served should be a/old-page?

That's correct. In httpd terminology this would be a "rewrite".