Change Details

wdqs-proxy needs the capability to control the semantic of incoming queries and block `UPDATE`s. In the current architecture, this is handled by nginx assigning a specific header that instructs Blazegraph to reject SPARQL UPDATE queries. In v2, we can centralize this logic in the passthrough layer. This would make the configuration easier for us to reason about (it's closer to query inspection, and federation allow list management) and simplify the setup for third parties (e.g., Wikibase Cloud and Suite). AC - [] wdqs-proxy has the capability to reject UPDATE queries. This should be default behaviour, configurable

wdqs-proxy needs the capability to control the semantic of incoming queries and block `UPDATE`s. In the current architecture, this is handled by nginx assigning a specific header that instructs Blazegraph to reject SPARQL UPDATE queries. In v2, we can centralize this logic in the passthrough layer. This would make the configuration easier for us to reason about (it's closer to query inspection, and federation allow list management) and simplify the setup for third parties (e.g., Wikibase Cloud and Suite). AC - [x] wdqs-proxy has the capability to reject UPDATE queries. (Edit: changed our minds about this part of the original AC: "This should be default behaviour, configurable ")

wdqs-proxy needs the capability to control the semantic of incoming queries and block `UPDATE`s. In the current architecture, this is handled by nginx assigning a specific header that instructs Blazegraph to reject SPARQL UPDATE queries. In v2, we can centralize this logic in the passthrough layer. This would make the configuration easier for us to reason about (it's closer to query inspection, and federation allow list management) and simplify the setup for third parties (e.g., Wikibase Cloud and Suite). AC - [x] wdqs-proxy has the capability to reject UPDATE queries. (Edit: changed our minds about this part of the original AC: "This should be default behaviour, configurable ")