It would be nice if the documentation here:
|
We support custom headers via a special file `_headers`. |
was more specific about the behavior which occurs here:
https://github.com/picosh/pico/blob/96bba54c241d82ae4916b3253f404d062490d0ff/pkg/apps/pgs/web_asset_handler.go#L252
That is:
- go regular expressions are supported, with the caveat that the first character must be '/'
- the match succeeds anywhere in the path, and it is not possible to match only the beginning of the path, since an expression starting with
^ will not be recognized as a valid rule; see isPathLine
- all header rules are checked in order and the last match "wins", headers do not accumulate, rules are not combined
- the example
/* might be more clearly commented if the intention is truly "zero or more slashes anywhere in path"
Here's a rule set that could help readers understand:
# generic rule must be listed first, since last match wins;
# note if /cross/ appears anywhere, even in the middle of the path,
# the match will succeed.
/cross/
Access-Control-Allow-Origin: https://user-othersite.pgs.sh
# serve files ending in .mjs as text/javascript instead of text/plain
/cross/.*\.mjs$
Access-Control-Allow-Origin: https://user-othersite.pgs.sh
Content-Type: text/javascript
It would be nice if the documentation here:
docs/posts/pgs.md
Line 325 in 7397057
was more specific about the behavior which occurs here:
https://github.com/picosh/pico/blob/96bba54c241d82ae4916b3253f404d062490d0ff/pkg/apps/pgs/web_asset_handler.go#L252
That is:
^will not be recognized as a valid rule; see isPathLine/*might be more clearly commented if the intention is truly "zero or more slashes anywhere in path"Here's a rule set that could help readers understand: