Can Bloom use Bloom-Request-Shard: 0 as the default when the header is not found?

[Anderson Faria Santos]

Hi there @valeriansaliou
Your fix for the double slashes in the pathname worked perfectly.
Now I do have one more question:

When there is no header Bloom-Request-Shard in the request, Bloom returns with a "bloom-status: REJECT". If shard 0 is always the default is it possible to make Bloom consider it is shard 0 even when there is no shard header?

For example, using Crisp's Status Page when I set an API address for it to check the health status, I can't set headers, so Bloom is always returning "bloom-status: REJECT". There are other use cases where requiring the header shard even for the default shard 0 won't be a great experience, like when you offer a public API.

By the way, do you have some ETA for the next version bump? I'm already testing in our staging and plan to soon deploy bloom and sonic at production. Will let you know when it happens.

Thanks!

[Valerian Saliou]

Hi @andersonsantos ; on your question, Bloom was designed to run behind an NGINX reverse-proxy. So your monitoring probe would hit against NGINX and not Bloom directly. NGINX would stamp the shard HTTP header to the request going to Bloom, as NGINX is virtual-host aware and thus could forward api1.example.com to shard 0, while it could forward api2.example.com to shard 1. This is how Bloom was designed to work.

There's currently no way to have it use a default shard if no HTTP header is set to select the shard; and I suspect it's better of this way as requiring the header makes it harder to deploy Bloom an incorrect way in a multi-shard environment, as Bloom errors if the sysadmin fails to add the correct shard to the request.

In your NGINX virtual host, you would simply add:

proxy_set_header Bloom-Request-Shard '0';

While proxying.

Bloom should not be exposed to the Internet directly, and should always be proxied over NGINX. In a world that requires every HTTP endpoint to run on SSL, I don't see the point of using Bloom as the public-facing reverse proxy as of 2019 😉

[Anderson Faria Santos]

Hi @valeriansaliou again, thank you for replying so fast.
We are not using Nginx, right now we use Cloudflare Argo Tunnels + Load balancing ( https://www.cloudflare.com/products/argo-tunnel/ ) which doesn't allow me to dynamically add headers on the requests.
What I did to solve this, for now, is to use Cloudflare Workers to intercept and add the request headers on the edge. This solved it. I will look into adding Nginx in our stack. By the way, do you use Bloom in front of your search API (Sonic)?

Thanks

[Valerian Saliou]

Perfect then!

Yes, we use Bloom in front of a NodeJS API that uses Sonic itself.