How is the Workers filter_id calculated? Is there a way to programmatically calculate it prior to deploying the new filter rule?
[edit to add] As I’m working through filter management logic, it occurs to me: How do I assign my development filter rules (https://api-dev.example.com/…) to a “development” script version and then assign production filter rules (https://api.example.com/…) to the production script?
[edit2] While attempting to use curl to upload an new filter, I’m getting the following error returned:
My curl command:
curl -s -X PUT \
-H "X-Auth-Email: EMAIL_REMOVED" \
-H "X-Auth-Key: KEY_REMOVED" \
-H "Content-Type: application/json" \
--data-binary "build/filters/FILTER_ID_REMOVED.json" \
-o "/tmp/deploy.sh.ejcLYT/output.json.TFLyBy" \
Is there a real difference between
Thanks to @adaptive,
--data-binary requires an
@ before the file name. With that fixed, I can now successfully push JS and JSON up.
Unfortunately, I’m still trying to figure out how to calculate the
Have you tried using routes api spec instead of filters?
Unfortunately, no. That’s for Enterprise plans.
On the non-Enterprise plans, I can have multiple hostnames, multiple routes,
and multiple KV stores. But I can only have a single script / filter|route destination. Seems a bit odd That I can almost deploy a
development stage beside a
production stage, but not quite. :-/
It seems to me that no matter what size plan is appropriate, you still need to live-test code changes before deploying them. Which, AFAICT, would require allowing two scripts per zone.
Filter IDs are randomly-generated when you create the filter. There’s no way to predict the ID; you have to GET the existing filter table in order to find out what the IDs are. We recognize this API is kind of difficult and we’re thinking of replacing it with an API in which you always upload the entire filter table in one request, thus the individual filters do not need IDs. However, this will of course make other (perhaps less-common?) use cases more difficult, in which you want to add or modify one filter without touching the others.
We know testing is difficult right now given the one-script-per-domain limit. workers.dev, when it is launched (soon!), will give everyone the ability to deploy and test multiple scripts without adding additional domains to your account. (You still will only be able to map one script to your real domain, though, at least for now.)
Ok, thanks for the info. Unfortunately, I wasn’t able to reserve any hostnames under workers.dev prior to APR11. Hopefully that’ll be available soon, because that will most likely solve my problem.
@jason28 workers.dev is now open to everyone!