Context
At KubeCon EU 2026, the OFREP discussion (recap) identified a challenge with routing and session affinity for OFREP requests.
Problem
OFREP uses POST requests with the evaluation context in the body. This makes load balancing and session affinity harder because routing decisions require parsing the request body. The etag header exists but isn't well suited for routing.
The targeting key is the natural routing key, but it often contains PII (emails, user IDs, etc.) and shouldn't be sent in plaintext as a header.
Proposal
Add a hash of the targeting key as a new request header in the OFREP spec. This would allow:
- Load balancers to route requests to consistent backends without body parsing
- Session affinity for stateful evaluation scenarios
- No PII exposure since only a hash is transmitted
The hashing should happen in the OFREP provider before the request is sent.
An ADR should be written to document the decision, including:
- Which hashing algorithm to use
- Header name convention
- Whether this is required or optional
Related
Context
At KubeCon EU 2026, the OFREP discussion (recap) identified a challenge with routing and session affinity for OFREP requests.
Problem
OFREP uses POST requests with the evaluation context in the body. This makes load balancing and session affinity harder because routing decisions require parsing the request body. The
etagheader exists but isn't well suited for routing.The targeting key is the natural routing key, but it often contains PII (emails, user IDs, etc.) and shouldn't be sent in plaintext as a header.
Proposal
Add a hash of the targeting key as a new request header in the OFREP spec. This would allow:
The hashing should happen in the OFREP provider before the request is sent.
An ADR should be written to document the decision, including:
Related