`arc.static` invocations without using `options` won't work when deployed to AWS without a domain
filmaj opened this issue · 0 comments
Describe the issue
Based on the code in https://github.com/architect/functions/blob/master/src/static/index.js, I think that if you deploy to AWS and don't have a domain set up for your app (and thus will have /staging
and /production
URL path prefixes for all routes), any usage of arc.static
without setting the second options
argument to {stagePath: true}
will yield an incorrect path (missing the first staging or production URL path segment). As far as I can tell, the only way to get arc.static
to correctly prefix the stage name is by using this second options argument.
Steps to reproduce
Create a basic arc app with:
- a
@static
pragma
- add a static asset under
public/
, e.g.public/foo.css
- a single
@http
route
- have the route use
@architect/functions
and e.g. print out the path to the static asset via a call toarc.static('foo.css')
- make sure no domain is associated to the app
Run it in sandbox and load up the http function: displays the right path (/_static/foo.css
).
Deploy it to AWS and load it up: womp womp. You'll get HTTP 403 responses from S3 because the stage URL prefix is missing: blahblahblah.amazonaws.com/_static/foo.css
should be blahblahblah.amazonaws.com/staging/_static/foo.css
.
Expected behavior
Works in both sandbox and deployed to AWS.
Additional context
The workaround is to call arc.static
with an options argument that looks like {stagePath: true}
. In sandbox, stagePath
will be ignored (as there is logic in arc.static
protecting against the local case). When deployed to AWS, it will get used in the path. Feels like this should be default behaviour? Though if I understand correctly, that will mess up apps that have and use a domain. Maybe it's simply a docs issue? Not sure.