It's recommended for SEO to have separate url per locale so I'm trying to create custom routes that is prefixed with {language}/ but I cannot get this to work. It fails to deploy with the following error:
An error occurred: ApiGatewayResourceLanguageVar - A sibling ({proxy+}) of this resource already has a variable path part -- only one is allowed (Service: AmazonApiGa00; Error Code: BadRequestException; Request ID: <redacted>).
Any ideas on how to solve this?
Interesting. I believe what's happening here is that the catch all route added by the plugin for rendering the next 404 page, uses the path variable /{proxy+} and that is conflicting with your homepage path /{language} and potentially any othe path that starts with /{language}/.
For example, a request comes in with /en or some nonsense /xyz , api gateway wouldn't know whether to match using /{proxy+} or /{language}.
I never particularly liked using a catch all route like that just for rendering next error pages but seemed to do the job fine until now 馃槃 Don't know right now how this can be solved but I'll look into it.
Also, is worth thinking about how this would work in next 9 dynamic route segments as I'm planning to support that soon.
@danielcondemarin What if we could add our own custom router to the catch all handler, and also allow us to define the catch all url structure? That would allow us to create redirectors and other cool things. Well defined urls would still route directly to the lambda handler like it is right now.
@mekwall Did you try using a custom route for the _error page? For example:
plugins:
- serverless-nextjs-plugin
custom:
serverless-nextjs:
routes:
- src: _error
path: {language}/{proxy+}
I'm hoping this overrides the default /{proxy+} catch all route, athough I've not actually tried it.
I've got another idea similar to what you proposed but I think is worth trying this first.
@danielcondemarin Will try and report back with my findings. Thanks!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
Interesting. I believe what's happening here is that the catch all route added by the plugin for rendering the next 404 page, uses the path variable
/{proxy+}and that is conflicting with your homepage path/{language}and potentially any othe path that starts with/{language}/.For example, a request comes in with
/enor some nonsense/xyz, api gateway wouldn't know whether to match using/{proxy+}or/{language}.I never particularly liked using a catch all route like that just for rendering next error pages but seemed to do the job fine until now 馃槃 Don't know right now how this can be solved but I'll look into it.
Also, is worth thinking about how this would work in next 9 dynamic route segments as I'm planning to support that soon.