Here's a pull request that's an alternative implementation to #65.
A few high-level notes:
- I realized that Grow already has a way to specify whether a resource should be served at a path with a trailing slash or not. This configuration is specified in a content file's frontmatter or blueprint. Here's an example: https://github.com/jeremydw/grow-redirect-slashes-demo/blob/master/content/pages/about.html – this makes the problem in #65 much more about how Grow configures trailing slash behavior for object stores rather than how Grow builds filesets.
- When a pod is deployed, we should follow this configuration as best we can. This means for object store deployments (S3 and GCS) – ones that allow objects and directories to share the same basename – we can deploy resources with a configuration following exactly what the user has specified. (Local deployments, where objects and directories cannot share the same name, use the "suffix" configuration.)
- In the current version of Grow, there is no way for the developer to specify trailing slash behavior for object store deployments.
This patch adds a way for the developer to control trailing slash behavior, independently of how resources are built by Grow. This matches werkzeug's strict_slashes
parameter (http://werkzeug.pocoo.org/docs/0.10/routing/#maps-rules-and-adapters) or Django's APPEND_SLASH
(https://docs.djangoproject.com/en/1.7/ref/settings/#append-slash).
In this patch, when a developer configures an object store deployment with redirect_trailing_slashes: true
– any "leaf" resource (that is, any resource whose path doesn't end in a trailing slash) will be redirected using the object store's built-in redirect rule (for GCS, this redirects to $PATH/$MAIN_PAGE_SUFFIX
). redirect_trailing_slashes: true
is the current default behavior of Grow.
If a developer specifies redirect_trailing_slashes: false
– resources will be deployed to the object store exactly as they're specified in the pod's configuration. This means when a user visits a path /foo
, that resource will only be served if it exists. /foo/
causes a 404, as does /foo/index.html
(for example).
Here's a sample pod that demonstrates this configuration:
https://github.com/jeremydw/grow-redirect-slashes-demo
With redirect_trailing_slashes: false
(new behavior):
http://slashes-off.growlaunches.com/about-us (serves)
http://slashes-off.growlaunches.com/about-us/nested (serves)
http://slashes-off.growlaunches.com/about-us/ (404s)
http://slashes-off.growlaunches.com/about-us/index.html (404s)
With redirect_trailing_slashes: true
(current/default behavior):
http://slashes-off.growlaunches.com/about-us (redirects)
http://slashes-off.growlaunches.com/about-us/ (serves)
http://slashes-off.growlaunches.com/about-us/index.html (serves)
@vitorio – sorry for sitting on this so long, but I wanted to think this through, and I knew that we already had a way to specify whether or not a path should have a trailing slash or not. This configuration format matches Jinja2's and Django's configuration options, which I'm happy about.
What do you think? Does this meet your needs? Thanks!