Repository navigation
Implement CDN-Loop (RFC 8586) #3489
Description
RFC 8586 protects systems from intra-CDN infinite loops.
The basic requirement here would be to copy any cdn-loop header from an incoming HTTP request onto any outbound HTTP request(s).
Given that it is somewhat natural to implement "CDN-like" features in Spin, I think this should be an opt-out runtime-configurable feature.
Open questions around whether/how to expose this header to guests:
- Should it appear in inbound requests? I'd default to yes, but in some sense it may make the spin environment a little less portable.
- Should guests be able to add values? Seems fine to allow, in which case any outbound
cdn-loopheader value(s) must be sent after copied inbound value(s). - If the answer to both of the above questions is "yes", we should probably be smart about only copying the header if the guest hasn't already (which it likely would if simply forwarding a request).
Activity
kate-goldenring commentedon May 1, 2026
Could this be expanded into a way to configure the HTTP trigger to preserve a specific set of headers (and always return them)?
lann commentedon May 1, 2026
I think that would be a separate feature - this is about "forwarding"
cdn-loopin outbound requests.kate-goldenring commentedon May 1, 2026
ah true, maybe then the interface is on runtime config for an extended set of headers.
having a fixed set (starting with
CDN_LOOP) of permitted forwarding headers seems like it could be a fine v1. IMO, it seems to make sense to start by only forwarding it if it is set incoming. We can always later add the functionality to always set it (and handle the case of it being set gracefully).lann commentedon Jun 3, 2026
Ref bytecodealliance/wasmtime#13510 should resolve WebAssembly/WASI#919, making this possible with concurrent instance reuse.