Would it be acceptable to allow photon opensearch to accept arbitrary cache breaker parameters?

I would like to extend the komoot/photon github repo as follows. I’m happy to code up a PR for this, but I’d like to get some feedback on whether it would be accepted first. I tried to raise as an issue there, but I don’t have permissions, and the contributing document referred me here.

There is code at photon/src/main/java/de/komoot/photon/query/RequestFactoryBase.java at e212bc6a87ca97ccb7c827e3771eb9a43edf9f64 · komoot/photon · GitHub
which checks that all supplied request parameters on the URL are recognised. I’d like to change this to allow arbitrary request parameters, with any that are not recognised being ignored.

The reasoning behind this is that we are deploying this code behind a CDN (in our case Azure Front Door) that does request caching. Each time we reinstate the back end it is hard to do end to end testing because the CDN just returns a cached value for our test queries. The normal way to avoid this is to provide a query parameter on our test tooling such as “cache=some_unique_random_value” on a request, which means that each test query is unique and the CDN sends it to the origin.

One alternative would be to disable caching altogether, but that is likely to increase traffic on the back end from real users significantly. Another alternative would be to have only a documented cache breaker parameter supported.

Thanks

You don’t really need to change Photon to get what you need. Put it behind a nginx/apache and have them filter out the fake parameters before forwarding to Photon. Or get your CDN to do that.

1 Like

Both of those options are technically possible, but neither of them is very attractive.

  • Our CDN doesn’t have that capability to strip out parameters now unless we upgrade to a higher payment tier which is far more expensive, and this is in the context of a charity with essentially zero budget running off limited free credits, so that isn’t really an option.
  • We could put an NGINX reverse proxy in the way, but it feels like a sledgehammer workaround to have all user traffic pass through a gateway that is running purely to make our test flows easier. It adds another thing to maintain and that might fail, which might actually outweigh the value of being able to test the end to end flows.

From my perspective, it would be best practice if the code was permissive in what it allowed, and I’m not sure if that is an uncontroversial bug fix or goes against what the maintainers would accept.

Cheers, Pete

It’s certainly not a bug fix but asking to change the philosophy of Photon’s API. To do something like this you need to show that a) there is a clear benefit for a significant part of the users and b) it will not break any existing work flows or introduce any security concerns.

You are currently failing to show a) (you could obviously fix your deployment very easy on your side with very little extra work for you) and haven’t even started to address b).

So, no, sorry, this doesn’t look like an acceptable change to Photon.

2 Likes